I have to agree a little bit..
One other thing that bothers me is when I don't WANT to run docker. Some packages/services actually make it tricky to achieve this. With some time being spent reversen engineering.
Docker is cool don't get me wrong, but it might be a bit over used sometimes. And I really don't think it needs to be this 1 way solution to everything.
The youngsters in my work keep sticking everything on docker to avoid packaging problems. I just makes running coed in a stepthrough debugger impossible so far (I know its possible but I haven't had the time to make it work yet).
Yea, first you just have to get your debugger (and maybe the rest of your toolchain) installed in the container, along with your source code.. and then you run into things like crazy wonky terminal support.
Sucks if you want to use a more advanced debugger interface, because you're not going to install that in the container.
In my case it was just Python using `pdb` so it wasn't so bad. Though it does get extremely janky if you, say, run a server and hit it with multiple requests that all hit a breakpoint... you end up with your input being sloshed across multiple debug sessions!
Question is, if it is worth the hassle to setup for e.g. a small team with maybe 1-2 apps/services.
I think docker is great (although I'm more exited about the future prospects of WASM+WASI), but as a default choice for every single project, in my opinion it often adds more accidental complexity to the system than the value it really adds
Even just setting up a new laptop it's a win. I could develop across my laptop, office pc, chromebook and home pc with a project and the only dependencies to keep up to date are docker and git pull/push.
How often do you set up a new laptop? And you still need to keep the dependencies of the project itself updated and tested which is the bulk of the work.
Don't get me wrong I think docker adds a lot a value once a system / team goes beyond non-trivial scale. But what I often see are three things: 1. people in pre-mvp stage design and setup a system they think will be able to scale to millions of users when all they have is a landing page/email grab. The time is in my opinion better spent pushing the product forward. 2. people hide problems in containers instead of solving them. E.g. not wanting to deal with outdated versions. 3. people confuse something being easy to use with it being simple.
I at least put my daemon dependencies (databases, mostly) in a docker-compose file from the beginning, to keep that cruft off my machine, to isolate projects, to avoid implicit dependencies on my own platform's package manager (adding one for the Docker registry, yes, but at least that's not specific to my environment), and to make the service dependency installation process super-easy and clean for others. I do this even if I'm running the project itself directly on my machine, outside of Docker.
I know of a team that spent significant time getting their front-end to run in docker. Because they were having regular problems getting the app to run on the developers machines due to extremely outdated versions it depended on.
Oh no, we have a problem! Lets put the problem in a neat container. Now we have a problem with a layer of abstraction on top, soon to be two problems. Rinse and repeat ...
You can just... not run the application in docker, can't you? Check out the repo on your local machine and install all the dependencies yourself -- problem solved.
I completely agree. My team has spent the last several years building software we then deploy with Docker and Kubernetes, and looking back I think that our software would have been much better deployed as statically-linked binaries on simple Linux servers.
We're writing in Go, which means we already have the statically-linked binaries, which means we have a single file which needs to get deployed. What does Docker buy us? … a single file which gets deployed. We could get the same effect of Docker Hub by just scping versioned binaries.
Kubernetes is far worse, of course. It is an amazing ramshackle collection of disparate, ill-fitting parts which make everything 'easy' but nothing simple. It does buy us some useful things, but I don't think they are worth the cost.
A bunch of EC2 nodes running Debian, with a few dozen-line shell scripts to copy binaries around, would completely replace our usage of Docker and Kubernetes and drastically reduce the complexity of our system. We just don't need a lot of what Kubernetes does (no doubt others do), but we have to pay for it in complexity anyway.
I really do believe that in the future we will see a few companies be very successful by foregoing Docker + Kubernetes + Helm (yo dude, I heard your YAML was giving you problems so here's some more YAML to YAML your YAML into YAMLy submission!), and then a few years later we will all look back at this mess a little bit like people look at the Pet Rock craze.
Maybe you know how it is at Amazon, but your statement is definitely not true for two other FAANGs. It's well known that Kubernetes is the open-source version of tools that already existed within Google, and Kubernetes itself is part of some public-facing products. I work at Facebook, and we most definitely do have our own equivalent of Kubernetes. It's awful in all of the same ways IMO. We also build fat binaries (and I believe the same is true at Google) but that's orthogonal. So one point for your claim, two against. Maybe someone else can fill in the blanks for Apple and Netflix.
That's not the least bit inconsistent. You claimed that FAANGs do not run anything with the complexity of Docker or Kubernetes. The best thing I can say about that claim is that your information is clearly outdated. Some might call it a lie. Facebook and Google, at least, do use something with equivalent complexity, and the very thing that makes them awful is also the thing that refutes your claim. Don't claim to speak for all companies when you clearly don't know anything about more than one.
If you can keep the use-case constrained to that, I agree. If you ever find yourself having to couple those Go binaries with someone else's Python or node code, Docker making it simple to bundle all those binaries into a standard packing infrastructure will be nice-to-have.
At my previous job, we used a python script to rsync files -- very, very simple. I think it would have been much more difficult and error-prone with Dockers.
Oh geez, having a team of 24 engineers across multiple countries trying to maintain a common set of bash scripts that work for 12+ unique services sounds like a disaster.
Instead we have a single workflow for docker, whether it's going out to AWS or Kubernetes and all the services use an identical flow. Integration testing is a cinch since it's running actual, version matched postgres/redis/etc on the CI nodes which get spun up on demand and against the same docker image that'll get pushed out to production.
We haven't had a case of "Well it works on my machine why doesn't it work on yours!?" in a really long time since if it works in docker.. well it works in docker.
Exactly, docker standardizes something that was an otherwise nightmare to maintain across platforms and organizations. Next we need to standardize the orchestrator, my money is on kubernetes, but I wouldn't say it has won over everyone just yet.
The industry has standardized on Kubernetes for the orchestrator. If anything we are starting to see other container runtimes other than Docker as K8s added the CRI (Container Runtime Interface).
Well everyone at least wants to use Kubernetes. I'm not sure any organization really knows how to best use it yet, and nobody has a set of standards that have seen adoption.
Both the pro and the con of K8s is that it's exactly what you make of it and it's extremely flexible.
The author addressed exactly this type of comment. I don't see the real difference in complexity of maintaining 12+ bash scripts instead of the same number of Docker files. And for the deployment, the alternative given by the author is using fat binary.
> I don't see the real difference in complexity of maintaining 12+ bash scripts instead of the same number of Docker files.
With respect, I have to assume your experience is either in an ecosystem with really strongly-established best practices for bash (and someone with the job of enforcing said practices) or your organization has no more than two or three people maintaining those dozen-plus bash scripts (and is on its way to a headache when two of those people retire at the same time and your org tries to on-board someone new to read those scripts).
Because a Docker config makes it hard to accidentally wipe your filesystem instead of building a Docker image. Shell scripts make that less difficult (and any solution using shell to do something similar to Docker will have a bespoke layer of in-house code that should be correct but will require maintenance by your team to make sure nobody makes a change that turns it into a filesystem-eater).
It is easier because you can actually build that functionality locally with a docker container to test it out.
This is coming from someone that spent 10+ years maintaining a build system that was a mix of makefiles and shell scripts. It can be done but I don't know if it should.
Well-written ksh/bash is extremely light-weight, flexible, concise and easy to maintain. Changing shell or OS would be the headache, but easily outweighted by gains if used for the right jobs.
Unfortunately, maintaining it requires somebody who is familiar with ksh or bash, and they are tools with Byzantine syntax by modern aesthetics. They're also more firepower than needed for the problem domain of building and maintaining deployments---they have features one doesn't need and require library support for key features in the deployment problem domain.
You can code a deployment solution in c++ also, but it's not recommended.
Docker file produces what basically is a software package with all the required dependencies. Deploy it to some Docker host and it will most likely run. It will run on a developer laptop, a VM or in K8s/Mesos/Nomad cluster. Add some docker compose files and you'll be able to run your whole service locally with all the external dependencies if you think that's a good idea. Extra bonus is... target system requires Docker daemon only. So no extra work to support Ruby/Java/Go/Python runtimes.
Alternatively you can go and package tar files. Or create Debian/Red Hat/Nix/whatnot compatible packages and manage dependencies via a package manager. You can go with Snap or Flatpak to achieve ~ the same. However Docker images produced by the said Docker files will most likely just run on any of the said OSes with no or little additional work and probably on the OSX and Windows too. And people will be pretty happy that running docker build $some_opts will (likely) give them a working app/(micro)service and that they don't have to mess with $some_packaging_system to rebuild and test stuff locally. So I guess Docker files provide some extra flexibility even if the maintenance burden is matched to the one required for maintaining bash scripts.
Fewer than half the number of engineers with hundreds of unique services. We aren't "just" using a common set of bash scripts, but we do have few. It's not a disaster, and it just works. What we deploy to a testing environment is what we deploy to production. Not a disaster. Deployments are a single button push.
Building the framework for a new services is filling out a form, and everything needed gets generated, including automated documentation, life cycle jobs, repos in github, properly configured security groups, etc.
We are exploring Docker, and while Docker offers some nice advantages, the added complexity and additional points of failure needs to bring some major benefits, and need to solve real problems we have. Not imagined problems.
That hasn't been my experience with docker at all. Except for pretty simple projects, I can't remember a single project I've worked on where I could just follow the README/"Here's how to set it up" email/whatever and have it work the first time. Every time a new developer came in, we'd find out that some implicit assumption was baked in somewhere, and finding out where took hours or days because debugging the damn thing is almost impossible. Everyone eventually syncs their environment but that just conveniently provides the illusion of standardization and repeatability. It's the same kind of "standardization" and "repeatability" we used to get twenty years ago -- all standard and repeatable, as long as no one touches the Solaris box that hosts the production deployments and no one updates their workstations.
And that's just the "legitimate" stuff. The amount of hours that we've wasted on things like "X runs docker 1.9 but Y runs docker 1.10", or overlay bugs, or image pruning failures, is insane. Breaking things is an inevitable side effect of progress but maybe infrastructure software shouldn't break this much...
Far from me to say that 20+ engineers across the world maintaining bash scripts for a dozen services is better. I used to do that and it was extremely terrible. Even when everyone involved had years of experience and the mundane task of updating deployment scripts wasn't delegated to interns, the way it is today (for reasons that I am entirely unable to comprehend). Definitely far more terrible than Docker. Docker is not as terrible, but still pretty terrible.
I'm open to the possibility that I've been doing it wrong, and that every team I've worked in/every customer I've worked for has been doing it wrong. But this has been going on for like four years now and enlightenment doesn't seem to be any closer to hitting me...
I don’t wanna gaslight you but this doesn’t match my experience at all. I’ve literally never run into issues with something compiling info one version of docker but not another. Image pulling has been a problem sometimes on Kubernetes but you just need to configure the creds correctly and boom it works.
Hey, don't worry :-). Like I said, I'm open to the possibility that I've been doing it wrong this whole time, or that I worked on projects that kept hitting cornercases and their associated bugs. I'm glad that you didn't have to deal with any of the bad parts.
> having a team of 24 engineers across multiple countries trying to maintain a common set of bash scripts that work for 12+ unique services
At the last place I worked that had a truly tight devops operation, it was 3 DevOps people maintaining infrastructure for 200+ unique services. And most that infrastructure was building really useful junk that I've never seen available elsewhere, like daily email reports telling me about every error that was logged on any services that my team maintained, and a cool little web UI that monitored our message bus and generated a visualization of which services (and instances) were listening to what.
The actual deployment and process management infrastructure wasn't very complicated, either, based on what I saw from poking around in their source control. They were able to shave a whole lot of unnecessary complexity by enforcing rigid standards about how each process would be packaged and configured and whatnot, regardless of implementation language. It was up to the developers who wanted to take on $hot_new_langauge to figure out how make it behave right.
And that gets to my real worry about Docker. It's a way of dealing with messes, not by cleaning them up, but by sweepi^H^H^H^H^H^H hiding it behind an abstraction. It's like that meme image that floated around a while back - "But it works on my machine." "Then we'll ship your machine." And that's how Docker was born.
Which isn't to say that this is useless - I use Docker all the time, chiefly to do things like making sure I'll never have to manually futz around with managing multiple concurrent PostgreSQL installs ever again - but, at least in production, it still feels to me like high tech duct tape and chewing gum.
I think docker/containers are the opposite of abstraction. It's a reduction of variables and creates true predictability across very disparate systems.
It's, at best, semi-consistent. In the Dockerized stack I'm working on right now, individual services are configured using a mishmash of environment variables, files you volume in (each one with a different format), shell scripts you volume in that will modify configuration files on startup, Dockerfiles that create derivative images that replace configuration files with instance-specific configuration, Dockerfiles with a bunch of RUN commands to handle more surgical modification of the configuration that was baked into some standardized base image. . . it's just crazy how variable it is.
The obvious reply is, "Well, don't do that." And my general reaction to that idea is is, if you have the discipline to not do that with containers, you have the discipline to not do that without containers. Containerization is the stone in the soup.
With a extra little side barb of, Docker doesn't really leave you any choice but to get messy. If you go troll through Docker issues, there are plenty of long-standing threads with community members requesting features to help them simplify and standardize their Docker situation, and Docker maintainers habitually rejecting the ideas on the grounds that they can already achieve what they want using some version of the abovementioned horrible mess of different ways to do things.
I'm a developer, so, in a professional setting, I really shouldn't be having much reason to think about system package management.
From my perspective, the important things are that every single server should look identical to my applications, and there should be no room for confusion between me and devops about how to manage them, and their configuration should be standardized and straightforward and documented enough that devops actually owns the configuration, and isn't just acting as a sort of sock puppet for the dev team.
I'm personally of the opinion that less is more: Every time you add a tool, you add more nooks and crannies and places for dust bunnies to collect. So, to that extent, I guess my question is, "How does Nix improve determinism in a way that (say) RPM doesn't?"
If the motivation for the answer answer involves assuming that you've released a Lovecraftian horde of different languages and platforms that each have one or more of their own special snowflake package management systems all crawling all over each other to try and muck with the same global system environment, I'm gonna slam the lid back on that Pandora's box. I'm not gonna try letting them have their fun by hellbanning them to their own private parallel universes where they all get to think that they're mucking with the system environment. An insane asylum with locked doors is still an insane asylum. No, I'd rather kick that whole mess to the curb and instead say that only well-behaved applications that know how to color inside the lines get to run in the shared environments.
Obviously this attitude doesn't work if you're a cloud platform or a smartphone OS or some other agent that isn't able to impose very many rules on the authors of the software that runs on your platform. Thankfully, I am not and have never been a Google, so the KISS principle remains an option for me.
Yeah, I realize that this means I'm swimming against the current. My resumé would probably look a lot better to the (probable vast majority of) companies who are thinking, "Only 357,453 new hires to go until we're as big and complicated as Amazon, better start planning for it now!" if I changed my attitude. Perhaps I'm too old to learn new tricks.
Nah, not bye karm at all. I realize that's how devops is supposed to work. It's just that I've never seen it work that way IRL.
I suspect that the ideal of devops is only practical in very small companies. Past a certain scale, social factors become at least as important as technical ones in deciding how responsibilities will be divided. It's hard to feel confident about that having never seen "bonafide devops" even being attempted anywhere but on paper, though.
I would like to see more vetting in dockerhub and security in general, yes it's based on cgroups which are specifically security minded, but not all docker users are aware of this. A novice user pulling a random docker image, and running default as root is bound to cause some issues.
Docker itself is a good idea; a standard repository of other people's opaque binaries and an ecosystem discipline of "Just pull in whatever you need; who cares why it works or who maintains it?" probably less so.
The author's approach presupposes a devops "person" (side note: if you have a person in charge of ops, that person is an ops person, not a "devops" person, as devops is a process; either your org is on it or they aren't). If you want developers to launch to production with any degree of reliability, you're going to need either a lot of tooling support for your specific workflow, or you're going to use docker and a significant degree of creative blindness. The fat binary approach works great if you can build a fat binary - python and node are nearly diametrically opposed to compiled binaries in general, much less ones that include a list of dependencies. The docker image is the fat binary that our toolchain is set up to build and run.
You are assuming that developers have enough knowledge of Docker to deploy in production confidently. Why is it different for other ops skills? What "degree of reliability" does Docker adds over bash, for example?
It adds full environment reproducability. Essentially, "it works on my machine" -- "then we'll ship your machine". Nothing about docker in particular is meaningful, if they shipped VM images this would be identical, but docker streamlines creation and management of the entire OS image. It eliminates all differences between the developer's laptop and the production server.
>that person is an ops person, not a "devops" person, as devops is a process; either your org is on it or they aren't
"devops" has made the same slide to meaninglessness as "agile." At one point they might have meant something about the philosophy of getting a job done. They don't anymore. They're buzzwords for a bunch of mutually-incomparable ideas, and as long as we pretend there is still meat in the concepts we're just lending buzzwords credibility.
"devops" is a verbal pyrbar for whatever change management already wanted to make, and shouldn't be seen as much more than a string of characters to get a resume through a regular expression.
If I use Docker, I get to put "Docker" on my resume for the next job; if I use bash scripts I don't.
If I use React, I get to put "React" on my resume; if I use vanilla JS I don't.
If I use Kubernetes, I get to put "Kubernetes" on my resume.
If I use AWS, I get to put that on my resume, if I just spin up a Linux instance using Linode or etc, I don't
Of course, I would have to convince my boss to let me do all of these. But, he also wants to be able to put on his resume that he managed developers who used these things, so that's an easy task.
Many of these made perfect sense for the FAANG company they were developed for, but they are used at companies with 0.01% of the number of servers of those companies, and the basic reason is that both devs and managers want to pretend they are working at FAANG, so that someday they will work there.
Again, there are valid use cases for all of these, but there are also valid use cases for semi tractor trailers. It doesn't mean I should use one to get my groceries.
In other words, only the parts that they are trained and qualified to do, yes. The parts that a developer team lead or team manager would not be good at. Makes sense.
Hiring people is difficult, exhausting, time-consuming, and largely a crap shoot, since hiring consists of deducing a person's technical abilities with around 1-2 hours of interaction in a very limited scope.
If we could find a better way, we'd be using it. But, as it stands, recruiters and HR have only a few minutes per potential candidate to determine whether or not they meet the hiring manager's criteria. It's unreasonable to expect HR/recruiters to keep abreast of an ever expanding list of technologies and their analogs because that's not their core competency. Unless they are repeatedly told that GCP experience is worth like 70% of AWS experience (replace the values and technologies as you see fit), they aren't going to know that.
The solution seems pretty simple to me: get rid of the HR and recruiters, at least as having much power in deciding who to interview. That's the hiring manager's job. He knows what kind of person he's looking for, so let him make decisions. Why would you let some non-technical person decide who's qualified to be interviews? It makes no sense. At best, have the hiring manager give some very basic things to look for on resumes to the HR person, so they can screen out the people who are obvious wastes of time.
>If we could find a better way, we'd be using it.
It seems to me that the reason it's so bad is because, at many companies, HR people refuse to admit that they're incompetent at hiring technical people, and insist on inserting themselves into the process to a degree which is highly counterproductive. The only thing HR should be doing is helping hiring managers find the people they need, and otherwise staying out of the way. The bulk of the HR person's time should be on other tasks: personnel issues with existing employees, helping new employees get situated, maybe interpersonal issues, etc. The hiring manager can afford to spend an hour a day looking through resumes and giving good ones back to HR to recruit.
This is assuming technical hiring manager, which may often not be so. Also, a team often wants new hires with all the latest buzzword experience as they are too swamped themselves.
Maybe have experienced different approaches, but where I've worked, the hiring manager told HR what skillset they needed and HR would fire over resumes for the team to look at and decide who to bring in. Our team decided 100% who to hire and not.
So, basically what you're talking about already happens at every company I've been involved in hiring at. HR posts the job posting from the manager, forwards resumes that look good. The do perform the initial non-technical interview, but teams handle technical interviews as they see fit. HR is only involved to present the offer.
Because of that, I took the parent comment to say that HR should be better at resume fishing. Meaning, they should understand technological equivalencies better, like MySQL and Oracle are somewhat equivalent or related skills but Bash and Elasticsearch are not. This is what recruiters are supposed to do; obviously most are bad at it, but his is largely because few SWE/SysAdmins/DevOps are going to pivot into recruitment.
It would be cool if the industry let us play "Confident Applicant's Gambit": I will agree to work for you, dubious but reputable employer, for six weeks to prove my mettle.
At the end of the six weeks, we part ways unless I have clearly demonstrated I am in fact, the genuine article, at which point you owe me back pay, and commence my salary which is about 140% of what you would normally pay someone. Quite a bargain for you.
The intention of this being, the employer is not at risk for slave labor, but the applicant is clearly wasting their time if they know they are not genuinely solving a problem the employer has for the given salary.
Unfortunately temp-or-contract-to-hire is automatically the bottom 1/3 of available people. A CHRO thought this was a brilliant solution to the six-month searches those silly people in IT kept complaining about.
Been there, done that, it doesn’t work in practice. We had to unwind nearly all of them after a few weeks, and all the on boarding wasted copious amounts of time for existing staff.
I commented elsewhere, but this is how it works at every job I've ever had and interviewed for. And I'm not some "SV ninja coder" either, I'm just a regular Joe working regular jobs. Hiring manager tells HR to post a job, they send over the resumes that they get, and schedule interviews with anyone who looks good.
With my last three jobs, the involvement with HR was limited to initial phone screen, asking about salary and legal status, then onto the hiring manager for the rest.
It's a bit more than that; there's a reason the next job cares that Docker, React, or Kubernetes are on your résumé.
If you use Docker, you get to claim that you're familiar with a framework atop a lower-level abstraction, and the lower-level abstraction is flexible to the point of incomprehensibility; few people enjoy maintaining someone else's bespoke shell script environment, and there's not much of a forcing function to cause standards to exist in that abstraction layer for doing a specific task (creating and managing deployable artifacts).
React vs. JS and Kubernetes vs. "Our previous sysadmin's solution built with hair-pulling and rage before they quit to embrace the life of the humble riverboat captain" follow the same pattern. The frameworks and toolchains listed are standards that allow someone who has solved that common business use-case at one organization to solve that use-case at another org with minimal spin-up time (vs. the time to learn bespoke solutions to do the same thing). Many people having the same problem domain to solve is how standards come to exist.
No, the rage extends to the developers too. Writing all of the yaml for a full service requires a fair bit of understanding of what's going on in k8s. And helm templating.
It's hair-pulling and rage that results in forward progress on a fungible toolchain (as opposed to hair-pulling and rage that results in a bespoke one-company ecosystem where you leave behind more than half the useful experience you gained when you transfer to a company based upon ecosystem fundamentals utterly different from the ones bought with the blood, sweat, and tears of solving the problem at the first place).
Speaking as someone using EKS: No, no it doesn't. The only thing we really handed over to someone else was the challenge of running a control plane. We still have to roll our own node images (for compliance reasons, the default images are insufficiently secure), still have to work directly with AWS to get larger etcd clusters, still have to manage the cluster itself...
The trouble has barely been below the threshold of pain to just run our own control plane.
Absolutely no it does not. I work with GKE and EKS almost exclusively and it compounds the headaches most of the time.
There is varying support for Kubernetes resources in both and all kinds of vendor-specific ways you need to do things to keep you locked in.
Every single managed Kubernetes solution available is a unique, special snowflake. Most folks in-house ones are the same. Saying that Kubernetes isn't some bespoke solution is a myth.
Kubernetes is a collection of haphazardly-assembled components in varying states of maturity and that landscape changes dramatically with minor release versions (GKE's Stable release branch is still 1.13, for example). YMMV.
> There is varying support for Kubernetes resources
I dunno, EKS not having built-in support for Ingress objects is a pretty large and obvious elephant in the room.
I'm not playing this game. I've stated my experiences and suggested the level of interaction I've had with the platforms in dollar figures enough to be comfortable with what I'm saying here.
> I dunno, EKS not having built-in support for Ingress objects is a pretty large and obvious elephant in the room.
Which is actually not a big deal. K8s ingress objects are not very flexible, and most users in my experience tend to use customized solutions (e.g. ambassador) where you use a Network Load Balancer. Ingress objects are fully supported in GKE.
> I'm not playing this game. I've stated my experiences and suggested the level of interaction I've had with the platforms in dollar figures enough to be comfortable with what I'm saying here.
You started playing this "game" by dropping numbers on how many $$s you've managed and asking that other believe you because of that. I was simply asking you to provide specific instances of the pain you're stating you see. The one instance you've provided isn't really that big of a deal.
yeah but for fighting with all the details once upfront you get an infinitely replicable environment.
not just scalability but you can have as much test environments, all identical, spinning up with an apply. and the next guy in line can do it too! possibly with a convenient front-end and little understanding, so you can spend your skills elsewhere
Maybe I'm particularly unfortunate, but that wasn't my experience at all. It's either bash scripts that make you want to pull your hair out, or yaml files that make you want to pull your hair out.
The same people who wrote these bash scripts are writing yaml files, and with k8s there are infinitely more interesting ways to bork your jobs.
> and the basic reason is that both devs and managers want to pretend they are working at FAANG, so that someday they will work there.
Strongly disagree. The reason they prefer Docker is that nobody wants to read your bash script. They want a standardized set of tools they can familiarize themselves with using curated examples and a large community.
Exactly. Every developer is always running a build-resume thread in his mind at the background, which drives choices many a times.
But why does it happen?
May be, there's no way for the developer to claim the value driven, and thus these skills end up being the proxy to be showcased!
If a developer's resume mentioned "got a 40% reduction in total operating cost of the supply-management-pipeline by enabling automated operations and reduced errors by 20% over a year, and helped drive sales up by about 30% over two years", this would NEVER get picked up by a recruiter - who would just be skimming the resumes for specific keywords. Worse, it could be an automated tool scanning the resume.
Also, in the general scheme of things, developers are kept off the real value outcomes for a reason - to prevent them from understanding their true value. Cause, it is good for business! :P
All of these combine to cause developers from not understanding the quantum of value being driven by their efforts, and thus to compensate for the lack of this important info - and to compensate for the shortcomings of the industry standard "job-description" templates that bother only about skills-and-number-of-years (as opposed to value-outcomes-driven-over-unit-time) make it harder for developers to really understand (and then showcase these in their resumes).
I’m actually looking for a job and this has come up more than once.
I agree with you for the most part.
Docker isn’t all that difficult to use and I don’t even see why they bother asking. I just laugh and tell them, yeah, I know docker, along with being quite proficient in Linux in general and other deployment technologies. I don’t see the point of asking developers if they know docker. If you can learn to code, you can learn the basics of docker in 15 minutes.
React and frameworks are more specific and I can see why asking about those for developer roles is more appropriate.
AWS is so damn big at this point that I don’t know what they are really asking by just saying “AWS”. Sure, I know about the core AWS stuff, but I’m not proficient in really specific AWS CloudFormation templates or AWS IAM policies and stuff. And I’m not sure most developers outside of devops should be responsible for such a thing. For day-to-day software engineering, I shouldn’t need to touch the servers - that should be handled by a CI process and/or devops persons.
Aren't those orthogonal (i.e. have little to do with each other)? Why would Gitlab/Azure DevOps Pipelines (CI/CD tools) make Docker (a container engine) irrelevant?
Docker may be over-used, but, when managing hundreds of instances of machines, it's really useful to have deploys/redeploys/updates:
- Immutable (the instance is effectively frozen as an image)
- Has dependencies baked in (don't have to worry about whether the app was run on xenial/bionic,etc.)
- Identical (people are disincentivized to make ad-hoc modifications to instances)
Well there's the rub. Most developers aren't going to manage hundreds of machines. My current company has thousands of customers, over a hundred employees, and makes tens of millions in profit. We've got two dozen servers (VMs) and obviously less than that in actual machines.
The scale at which you need hundreds of instances is probably when it does make sense to use something like Docker.
My last company had 2400 OpenShift cpu cores assigned just to unused OpenShift projects. I'm sure the number of used OpenShift cores was in the tens of thousands.
For instance just a Kafka consumer that needs to sync a few billion records to cassandra and ElasticSearch by itself may use 50 cores.
Also, a lot of smaller (and mid-sized) companies end up with tons of instances and all kinds of complex server infrastructure because their code is mind-bogglingly inefficient and falls over without it. You either fix their mountain of broken shit or you throw "cloud" at it.
Relatedly, I've seen a lot of "we need to avoid & transition away from SQL database servers, they're slow and don't scale" in the wild when the problem is actually that the way SQL is being used is not simply not-advanced, but incompetent. Hundreds to thousands of queries per page load for no good reason, useless caching, little attention paid to indices, that kind of thing. Often Rails is involved. :-/
Docker lets you have a standard easy to run reproducible description of a system (service + all dependencies) as code for any service. It's a fat-binary for anything that is also the build env for that binary. Not all languages support native fat-binaries and even those that do you still need a way to reproducibly build that binary (CI doesn't count because local testing builds can't reproduce it).
a) do not want to give people/scripts access to the machine.
b) do not want to employ a bunch of people whose sole purpose is to manage these machines.
Being able to provision (for instance) an Openshift project in a click to deploy docker containers solves those problems.
Yes, those are not problems that a startup or a small business has, but these are problems that all large enterprises with sensitive data have.
Docker is a standard that anyone knows. Is it the best standard? Who knows, but it is a platform and a standard that has built an ecosystem. That fact alone will make it better than any product or custom-built deployment solution that has to be maintained by a team of engineers.
I notice that once you're invested, time and effort wise, in doing something one way, and it works, the general unwillingness to learn different or newer ways of doing the same things increases rapidly. Overcoming such prejudice requires understanding and accepting the incentives for further investing time and effort to accustom with newer technology.
Use-case driven technology fit is just one incentive. There are other incentives like resume enhancement, participation in communities where there is rapid development, FOMO / fear of being a dinosaur, the reputation of being known as someone well versed with the latest technologies, monetization via online courses/tutorials. These are just a few I could think of, I'm sure there are more.
In my relatively short career, I saw this playing out with NoSql databases, microservices architecture, SPA (AngularJS), NodeJS, responsive websites, blockchain and more recently, ReactJS, data-science (AI/ML) and containerization.
Each one of these, at some point or the other, have been used in cases where the problem space was completely solvable without using said technology but was introduced for some other incentive.
Say what you will but this rapid change is what makes and keeps this space moving, interesting, inspiring and well-paying.
The author has the boldness of saying that anything that does not produce a single artifact (golang binary or fatjar) is a language that should not be used an that they were errors of the past and we should get rid of them (citing explicitly PHP, Ruby and Python).
Now, if we want to think that languages and whole ecosystems (libraries, bugs and edge cases fixed, developers and companies whose code base is written in such language) can be changed easily, then the author take on Docker is right. In such a world Docker doesn't add anything useful. But the real world is quite different and it's not going to change for the author, so Docker (or "containers") is still adding something valuable and it's not a "bet" to me, at all.
By expecting Docker users to know more than they do, the author thinks they're dumber than they are.
Docker users are mostly folks who specialize in other areas of programming, to whom Docker popularized affecting "fat binaries" out of PHP/Ruby/Python/node apps via chroot. Chroot was already well known to ops folks, but was arcane to most webapp devs.
We're not ops experts who have been confounded by marketing, we're ops amateurs for whom Docker cracked the nut of chroot legibility.
The author hates on Docker in comparison to other fat binary techniques; he ignores that pro-Docker advocates are comparing it to not using fat binaries at all.
I don't trust people who like their software tools. I can trust some of the people who believe that their usecase justifies the cost of a tool, as long as they can also articulate it's limitations. If someone doesn't understand the environment and problem a tool solves well enough to rattle off a laundry list of good, bad and ugly design decisions, then their baseline analysis doesn't have any utility.
It's a subtle distinction, because once someone is primed that these are the two options, everyone thinks they're in the second category. You have to give someone enough rope and hope they offer up how much they "love" their toys.
I like this article because the container toolset ecosystem needs criticism to evolve. And we don't see enough of it.
Docker is dead and k8s is hyped up by a bunch of clueless vcs and an army of marketing monkeys called "developer evangelists" that get paid by the tweet. Said evangelists are people that failed at even the most jr software roles so why would anyone listen to them.
Docker is the fatbinary that he is talking about. It supports all-the-languages and runs just about everywhere.
The article ignores the fact that companies do not have the time, money, expertise, and desire to re-write their apps in a language that will compile down into a binary. There is a reason so many successful companies use PHP and Ruby. They work and make those businesses money. Taking a golang binary and building it into a tiny scratch docker image would be fantastic too.
In a previous job we ran hundreds of bare metal machines that were built up using puppet. It was amazing in the sense that it was somewhat standardized and could scale well. I still wish every service was using docker. We had php, ruby and golang services and getting all of those dependencies running was a pain. Not only did you have specific machine images to support each language, you had to support each service type too. If they were in docker containers we could have had one machine time and moved the docker images around.
Docker (and docker-compose) is super useful for local development environments. Sure, there are problems with docker on windows and with non-root containers. But docker is way better then most of the other tools I used for this (vagrant and whatnot).
A main problem in my opinion is, that old images are no longer published (or removed from dockerhub). I doubt very much, that you can build docker images that are written now in 2030.
But I assume the same happens with Packer + Terraform. In both cases you need to make sure the image is saved and accessible at a place you control, because the build will stop working at some point in time. Also the nice thing about docker is, it runs local (developer machine) and in production. I am not sure how you archive that with AMIs.
Building fat binaries is only easy for some specific languages and tools. In docker, it is easy for everything. At the end docker gives you a standardized way to deploy (image, environment variables, network, volumes and off you go!).
Now about docker in production. I had lots of problems with that. But if you use docker for local and don't have a ops department, it is the natural way to go. You run your integration tests with the same image that later runs on prod, so you don't need to worry, what stack is running on in a different environment. As a developer with a fully automated CI chain, I can control the entire deployment from my IDE (Dockerfile, Jenkinsfile, ...). My college can review the entire deployment in the PR (code-changes and infrastructure changes). And also docker has for most external software a ready to use image. Those are big benefits for small dev teams in small companies.
Also cloud providers offer docker tooling like a private image repository and docker support in most CI tools. I mention all of this, because the tooling around a container solution is important. You may dislike docker, but it integrates in most cloud providers and has images for almost everything.
The argument about complexity is true. If something doesn't work and you have no idea about the parts under the docker layer then its game over. But this is a very general argument against complexity. Complexity in software makes everything easy until you need to go down an abstraction layer. Nobody forces you to run your MySQL or Elasticsearch in docker container. This is definitely an unnecessary (and potentially dangerous) layer of complexity.
But to run the 10 years old PHP 5 application that needs memcached version 0.1.5, docker is very very useful: you spend a week to put all that legacy stuff in an docker image, push the image and all the team members can run it locally. Even the designer that knows a bit of jquery can run "docker-compose up" on his windows machine.
This might be the most short sighted article I have ever read. One of humanity's greatest achievements was the creation of the intermodel shipping container(https://en.wikipedia.org/wiki/Intermodal_container). We literally would not live in the world of convenience we have today without it.
But imagine what the curmudgeon of the day had to say about this. "Why do I need to use this specific container? This container has all these problems... and on and on"
Oof, this didn’t age well. Sounds like the OP didn’t want to understand the benefits of Docker at scale in a large, heterogenous corporation and has stuck their head in the sand because their uses cases didn’t need it.
His arguments seem week. I’ve used both docker and k8s for couple of years now. Sure there is a learning curve but because shit is consistent and sane we’ve been able to have better uptimes, and our pages went significantly down(self healing and auto-scaling properties of k8s are a god send).
Before we used to fab-ssh into the servers, manually ask some human at softlayer to provision new servers, bash script install things, and use native package managers like pip install. Fun fact. Pip is not deterministic. Until package-lock came, npm wasn’t deterministic. Things that worked in dev and staging would end up borking prod and we’d be serving 500s. Other language package managers had similar issues.
I see docker as just a glorified package manager. Make a docker file, build an image, run the same image in prod/dev/stage for consistency.
From what I've seen, Docker usually gets used when someone has a difficult-to-run app, usually due to many dependencies or a cryptic barely-documented jump-through-hoops-of-fire setup. So they dockerize it. Instead of trying to improve the app, they've essentially thrown up their hands in defeat and dockerized it. Which is a legitimate strategy in many cases, but too often it's the lazy way out.
133 comments
[ 4.0 ms ] story [ 257 ms ] threadDocker is cool don't get me wrong, but it might be a bit over used sometimes. And I really don't think it needs to be this 1 way solution to everything.
One step forward two steps back.
Sucks if you want to use a more advanced debugger interface, because you're not going to install that in the container.
In your `debug` build, include a debugger. Use this to debug. In your `release` build, just include the app and its dependencies. Use this in prod.
I think docker is great (although I'm more exited about the future prospects of WASM+WASI), but as a default choice for every single project, in my opinion it often adds more accidental complexity to the system than the value it really adds
Don't get me wrong I think docker adds a lot a value once a system / team goes beyond non-trivial scale. But what I often see are three things: 1. people in pre-mvp stage design and setup a system they think will be able to scale to millions of users when all they have is a landing page/email grab. The time is in my opinion better spent pushing the product forward. 2. people hide problems in containers instead of solving them. E.g. not wanting to deal with outdated versions. 3. people confuse something being easy to use with it being simple.
Containers have uses but they're being treated like silver bullets and building new levels of unnecessary complexity in many cases.
Oh no, we have a problem! Lets put the problem in a neat container. Now we have a problem with a layer of abstraction on top, soon to be two problems. Rinse and repeat ...
The comments on the article are not kind, however [1][2].
1. https://www.reddit.com/r/devops/comments/8j9yrn/docker_is_th...
2. https://www.reddit.com/r/docker/comments/8jk22u/docker_is_a_...
[1] https://news.ycombinator.com/item?id=19828317
We're writing in Go, which means we already have the statically-linked binaries, which means we have a single file which needs to get deployed. What does Docker buy us? … a single file which gets deployed. We could get the same effect of Docker Hub by just scping versioned binaries.
Kubernetes is far worse, of course. It is an amazing ramshackle collection of disparate, ill-fitting parts which make everything 'easy' but nothing simple. It does buy us some useful things, but I don't think they are worth the cost.
A bunch of EC2 nodes running Debian, with a few dozen-line shell scripts to copy binaries around, would completely replace our usage of Docker and Kubernetes and drastically reduce the complexity of our system. We just don't need a lot of what Kubernetes does (no doubt others do), but we have to pay for it in complexity anyway.
I really do believe that in the future we will see a few companies be very successful by foregoing Docker + Kubernetes + Helm (yo dude, I heard your YAML was giving you problems so here's some more YAML to YAML your YAML into YAMLy submission!), and then a few years later we will all look back at this mess a little bit like people look at the Pet Rock craze.
This is a deliberate choice, at least in Amazon.
[1]:https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
> It's awful in all of the same ways IMO.
> So one point for your claim, two against.
It's awful but at the same time it's a claim against... interesting.
At my previous job, we used a python script to rsync files -- very, very simple. I think it would have been much more difficult and error-prone with Dockers.
Sounds like you're looking for Ansible.
Instead we have a single workflow for docker, whether it's going out to AWS or Kubernetes and all the services use an identical flow. Integration testing is a cinch since it's running actual, version matched postgres/redis/etc on the CI nodes which get spun up on demand and against the same docker image that'll get pushed out to production.
We haven't had a case of "Well it works on my machine why doesn't it work on yours!?" in a really long time since if it works in docker.. well it works in docker.
Both the pro and the con of K8s is that it's exactly what you make of it and it's extremely flexible.
the company was sold for scrap shortly after this article https://thehftguy.com/2019/10/22/the-demise-of-docker-and-th...
With respect, I have to assume your experience is either in an ecosystem with really strongly-established best practices for bash (and someone with the job of enforcing said practices) or your organization has no more than two or three people maintaining those dozen-plus bash scripts (and is on its way to a headache when two of those people retire at the same time and your org tries to on-board someone new to read those scripts).
This is coming from someone that spent 10+ years maintaining a build system that was a mix of makefiles and shell scripts. It can be done but I don't know if it should.
You can code a deployment solution in c++ also, but it's not recommended.
Alternatively you can go and package tar files. Or create Debian/Red Hat/Nix/whatnot compatible packages and manage dependencies via a package manager. You can go with Snap or Flatpak to achieve ~ the same. However Docker images produced by the said Docker files will most likely just run on any of the said OSes with no or little additional work and probably on the OSX and Windows too. And people will be pretty happy that running docker build $some_opts will (likely) give them a working app/(micro)service and that they don't have to mess with $some_packaging_system to rebuild and test stuff locally. So I guess Docker files provide some extra flexibility even if the maintenance burden is matched to the one required for maintaining bash scripts.
Building the framework for a new services is filling out a form, and everything needed gets generated, including automated documentation, life cycle jobs, repos in github, properly configured security groups, etc.
We are exploring Docker, and while Docker offers some nice advantages, the added complexity and additional points of failure needs to bring some major benefits, and need to solve real problems we have. Not imagined problems.
And that's just the "legitimate" stuff. The amount of hours that we've wasted on things like "X runs docker 1.9 but Y runs docker 1.10", or overlay bugs, or image pruning failures, is insane. Breaking things is an inevitable side effect of progress but maybe infrastructure software shouldn't break this much...
Far from me to say that 20+ engineers across the world maintaining bash scripts for a dozen services is better. I used to do that and it was extremely terrible. Even when everyone involved had years of experience and the mundane task of updating deployment scripts wasn't delegated to interns, the way it is today (for reasons that I am entirely unable to comprehend). Definitely far more terrible than Docker. Docker is not as terrible, but still pretty terrible.
I'm open to the possibility that I've been doing it wrong, and that every team I've worked in/every customer I've worked for has been doing it wrong. But this has been going on for like four years now and enlightenment doesn't seem to be any closer to hitting me...
At the last place I worked that had a truly tight devops operation, it was 3 DevOps people maintaining infrastructure for 200+ unique services. And most that infrastructure was building really useful junk that I've never seen available elsewhere, like daily email reports telling me about every error that was logged on any services that my team maintained, and a cool little web UI that monitored our message bus and generated a visualization of which services (and instances) were listening to what.
The actual deployment and process management infrastructure wasn't very complicated, either, based on what I saw from poking around in their source control. They were able to shave a whole lot of unnecessary complexity by enforcing rigid standards about how each process would be packaged and configured and whatnot, regardless of implementation language. It was up to the developers who wanted to take on $hot_new_langauge to figure out how make it behave right.
And that gets to my real worry about Docker. It's a way of dealing with messes, not by cleaning them up, but by sweepi^H^H^H^H^H^H hiding it behind an abstraction. It's like that meme image that floated around a while back - "But it works on my machine." "Then we'll ship your machine." And that's how Docker was born.
Which isn't to say that this is useless - I use Docker all the time, chiefly to do things like making sure I'll never have to manually futz around with managing multiple concurrent PostgreSQL installs ever again - but, at least in production, it still feels to me like high tech duct tape and chewing gum.
The obvious reply is, "Well, don't do that." And my general reaction to that idea is is, if you have the discipline to not do that with containers, you have the discipline to not do that without containers. Containerization is the stone in the soup.
With a extra little side barb of, Docker doesn't really leave you any choice but to get messy. If you go troll through Docker issues, there are plenty of long-standing threads with community members requesting features to help them simplify and standardize their Docker situation, and Docker maintainers habitually rejecting the ideas on the grounds that they can already achieve what they want using some version of the abovementioned horrible mess of different ways to do things.
I'm a developer, so, in a professional setting, I really shouldn't be having much reason to think about system package management.
From my perspective, the important things are that every single server should look identical to my applications, and there should be no room for confusion between me and devops about how to manage them, and their configuration should be standardized and straightforward and documented enough that devops actually owns the configuration, and isn't just acting as a sort of sock puppet for the dev team.
I'm personally of the opinion that less is more: Every time you add a tool, you add more nooks and crannies and places for dust bunnies to collect. So, to that extent, I guess my question is, "How does Nix improve determinism in a way that (say) RPM doesn't?"
If the motivation for the answer answer involves assuming that you've released a Lovecraftian horde of different languages and platforms that each have one or more of their own special snowflake package management systems all crawling all over each other to try and muck with the same global system environment, I'm gonna slam the lid back on that Pandora's box. I'm not gonna try letting them have their fun by hellbanning them to their own private parallel universes where they all get to think that they're mucking with the system environment. An insane asylum with locked doors is still an insane asylum. No, I'd rather kick that whole mess to the curb and instead say that only well-behaved applications that know how to color inside the lines get to run in the shared environments.
Obviously this attitude doesn't work if you're a cloud platform or a smartphone OS or some other agent that isn't able to impose very many rules on the authors of the software that runs on your platform. Thankfully, I am not and have never been a Google, so the KISS principle remains an option for me.
Yeah, I realize that this means I'm swimming against the current. My resumé would probably look a lot better to the (probable vast majority of) companies who are thinking, "Only 357,453 new hires to go until we're as big and complicated as Amazon, better start planning for it now!" if I changed my attitude. Perhaps I'm too old to learn new tricks.
P0wning solution together.
Not a position, a role, a team, etc..
Bye karm
I suspect that the ideal of devops is only practical in very small companies. Past a certain scale, social factors become at least as important as technical ones in deciding how responsibilities will be divided. It's hard to feel confident about that having never seen "bonafide devops" even being attempted anywhere but on paper, though.
"devops" has made the same slide to meaninglessness as "agile." At one point they might have meant something about the philosophy of getting a job done. They don't anymore. They're buzzwords for a bunch of mutually-incomparable ideas, and as long as we pretend there is still meat in the concepts we're just lending buzzwords credibility.
"devops" is a verbal pyrbar for whatever change management already wanted to make, and shouldn't be seen as much more than a string of characters to get a resume through a regular expression.
I imagine a devops person as someone who manages IDE licenses and possibly the company's docker registry and SCM server.
Again, there are valid use cases for all of these, but there are also valid use cases for semi tractor trailers. It doesn't mean I should use one to get my groceries.
If HR goes as low-level in hiring as "React Developer" then people have to play this game.
If HR would hire on something more substantial, it wouldn't matter if you did Linode or AWS, React or Angular, Docker or Bash scripts.
If we could find a better way, we'd be using it. But, as it stands, recruiters and HR have only a few minutes per potential candidate to determine whether or not they meet the hiring manager's criteria. It's unreasonable to expect HR/recruiters to keep abreast of an ever expanding list of technologies and their analogs because that's not their core competency. Unless they are repeatedly told that GCP experience is worth like 70% of AWS experience (replace the values and technologies as you see fit), they aren't going to know that.
>If we could find a better way, we'd be using it.
It seems to me that the reason it's so bad is because, at many companies, HR people refuse to admit that they're incompetent at hiring technical people, and insist on inserting themselves into the process to a degree which is highly counterproductive. The only thing HR should be doing is helping hiring managers find the people they need, and otherwise staying out of the way. The bulk of the HR person's time should be on other tasks: personnel issues with existing employees, helping new employees get situated, maybe interpersonal issues, etc. The hiring manager can afford to spend an hour a day looking through resumes and giving good ones back to HR to recruit.
So, basically what you're talking about already happens at every company I've been involved in hiring at. HR posts the job posting from the manager, forwards resumes that look good. The do perform the initial non-technical interview, but teams handle technical interviews as they see fit. HR is only involved to present the offer.
Because of that, I took the parent comment to say that HR should be better at resume fishing. Meaning, they should understand technological equivalencies better, like MySQL and Oracle are somewhat equivalent or related skills but Bash and Elasticsearch are not. This is what recruiters are supposed to do; obviously most are bad at it, but his is largely because few SWE/SysAdmins/DevOps are going to pivot into recruitment.
At the end of the six weeks, we part ways unless I have clearly demonstrated I am in fact, the genuine article, at which point you owe me back pay, and commence my salary which is about 140% of what you would normally pay someone. Quite a bargain for you.
The intention of this being, the employer is not at risk for slave labor, but the applicant is clearly wasting their time if they know they are not genuinely solving a problem the employer has for the given salary.
Been there, done that, it doesn’t work in practice. We had to unwind nearly all of them after a few weeks, and all the on boarding wasted copious amounts of time for existing staff.
HR isn't qualified to hire for technical positions, then, and team members should evaluate other potential team members.
With my last three jobs, the involvement with HR was limited to initial phone screen, asking about salary and legal status, then onto the hiring manager for the rest.
If you use Docker, you get to claim that you're familiar with a framework atop a lower-level abstraction, and the lower-level abstraction is flexible to the point of incomprehensibility; few people enjoy maintaining someone else's bespoke shell script environment, and there's not much of a forcing function to cause standards to exist in that abstraction layer for doing a specific task (creating and managing deployable artifacts).
React vs. JS and Kubernetes vs. "Our previous sysadmin's solution built with hair-pulling and rage before they quit to embrace the life of the humble riverboat captain" follow the same pattern. The frameworks and toolchains listed are standards that allow someone who has solved that common business use-case at one organization to solve that use-case at another org with minimal spin-up time (vs. the time to learn bespoke solutions to do the same thing). Many people having the same problem domain to solve is how standards come to exist.
If so, I've got some stories for you.
The trouble has barely been below the threshold of pain to just run our own control plane.
(Disclaimer: I work for AWS as a specialist solutions architect.)
There is varying support for Kubernetes resources in both and all kinds of vendor-specific ways you need to do things to keep you locked in.
Every single managed Kubernetes solution available is a unique, special snowflake. Most folks in-house ones are the same. Saying that Kubernetes isn't some bespoke solution is a myth.
Kubernetes is a collection of haphazardly-assembled components in varying states of maturity and that landscape changes dramatically with minor release versions (GKE's Stable release branch is still 1.13, for example). YMMV.
I gave enough detail that anyone familiar enough with both platforms should know some of the issues I'm talking about already.
I dunno, EKS not having built-in support for Ingress objects is a pretty large and obvious elephant in the room.
I'm not playing this game. I've stated my experiences and suggested the level of interaction I've had with the platforms in dollar figures enough to be comfortable with what I'm saying here.
Which is actually not a big deal. K8s ingress objects are not very flexible, and most users in my experience tend to use customized solutions (e.g. ambassador) where you use a Network Load Balancer. Ingress objects are fully supported in GKE.
> I'm not playing this game. I've stated my experiences and suggested the level of interaction I've had with the platforms in dollar figures enough to be comfortable with what I'm saying here.
You started playing this "game" by dropping numbers on how many $$s you've managed and asking that other believe you because of that. I was simply asking you to provide specific instances of the pain you're stating you see. The one instance you've provided isn't really that big of a deal.
not just scalability but you can have as much test environments, all identical, spinning up with an apply. and the next guy in line can do it too! possibly with a convenient front-end and little understanding, so you can spend your skills elsewhere
not for everyone, sure, but then which tool is?
The same people who wrote these bash scripts are writing yaml files, and with k8s there are infinitely more interesting ways to bork your jobs.
Strongly disagree. The reason they prefer Docker is that nobody wants to read your bash script. They want a standardized set of tools they can familiarize themselves with using curated examples and a large community.
Exactly. Every developer is always running a build-resume thread in his mind at the background, which drives choices many a times.
But why does it happen?
May be, there's no way for the developer to claim the value driven, and thus these skills end up being the proxy to be showcased!
If a developer's resume mentioned "got a 40% reduction in total operating cost of the supply-management-pipeline by enabling automated operations and reduced errors by 20% over a year, and helped drive sales up by about 30% over two years", this would NEVER get picked up by a recruiter - who would just be skimming the resumes for specific keywords. Worse, it could be an automated tool scanning the resume.
Also, in the general scheme of things, developers are kept off the real value outcomes for a reason - to prevent them from understanding their true value. Cause, it is good for business! :P
All of these combine to cause developers from not understanding the quantum of value being driven by their efforts, and thus to compensate for the lack of this important info - and to compensate for the shortcomings of the industry standard "job-description" templates that bother only about skills-and-number-of-years (as opposed to value-outcomes-driven-over-unit-time) make it harder for developers to really understand (and then showcase these in their resumes).
Also, an old classic on these lines - http://www.bruceblinn.com/parable.html - The parable of two programmers.
"I don't want to seem like a hack, so I'll do enterprisey things, so that nobody can call me a dumb guy" is another thing running in the background.
I agree with you for the most part.
Docker isn’t all that difficult to use and I don’t even see why they bother asking. I just laugh and tell them, yeah, I know docker, along with being quite proficient in Linux in general and other deployment technologies. I don’t see the point of asking developers if they know docker. If you can learn to code, you can learn the basics of docker in 15 minutes.
React and frameworks are more specific and I can see why asking about those for developer roles is more appropriate.
AWS is so damn big at this point that I don’t know what they are really asking by just saying “AWS”. Sure, I know about the core AWS stuff, but I’m not proficient in really specific AWS CloudFormation templates or AWS IAM policies and stuff. And I’m not sure most developers outside of devops should be responsible for such a thing. For day-to-day software engineering, I shouldn’t need to touch the servers - that should be handled by a CI process and/or devops persons.
It's not a replacement for Docker, but a very useful companion.
Well there's the rub. Most developers aren't going to manage hundreds of machines. My current company has thousands of customers, over a hundred employees, and makes tens of millions in profit. We've got two dozen servers (VMs) and obviously less than that in actual machines.
The scale at which you need hundreds of instances is probably when it does make sense to use something like Docker.
My last company had 2400 OpenShift cpu cores assigned just to unused OpenShift projects. I'm sure the number of used OpenShift cores was in the tens of thousands.
For instance just a Kafka consumer that needs to sync a few billion records to cassandra and ElasticSearch by itself may use 50 cores.
Relatedly, I've seen a lot of "we need to avoid & transition away from SQL database servers, they're slow and don't scale" in the wild when the problem is actually that the way SQL is being used is not simply not-advanced, but incompetent. Hundreds to thousands of queries per page load for no good reason, useless caching, little attention paid to indices, that kind of thing. Often Rails is involved. :-/
a) do not want to give people/scripts access to the machine.
b) do not want to employ a bunch of people whose sole purpose is to manage these machines.
Being able to provision (for instance) an Openshift project in a click to deploy docker containers solves those problems.
Yes, those are not problems that a startup or a small business has, but these are problems that all large enterprises with sensitive data have.
Docker is a standard that anyone knows. Is it the best standard? Who knows, but it is a platform and a standard that has built an ecosystem. That fact alone will make it better than any product or custom-built deployment solution that has to be maintained by a team of engineers.
Use-case driven technology fit is just one incentive. There are other incentives like resume enhancement, participation in communities where there is rapid development, FOMO / fear of being a dinosaur, the reputation of being known as someone well versed with the latest technologies, monetization via online courses/tutorials. These are just a few I could think of, I'm sure there are more.
In my relatively short career, I saw this playing out with NoSql databases, microservices architecture, SPA (AngularJS), NodeJS, responsive websites, blockchain and more recently, ReactJS, data-science (AI/ML) and containerization.
Each one of these, at some point or the other, have been used in cases where the problem space was completely solvable without using said technology but was introduced for some other incentive.
Say what you will but this rapid change is what makes and keeps this space moving, interesting, inspiring and well-paying.
Now, if we want to think that languages and whole ecosystems (libraries, bugs and edge cases fixed, developers and companies whose code base is written in such language) can be changed easily, then the author take on Docker is right. In such a world Docker doesn't add anything useful. But the real world is quite different and it's not going to change for the author, so Docker (or "containers") is still adding something valuable and it's not a "bet" to me, at all.
Docker users are mostly folks who specialize in other areas of programming, to whom Docker popularized affecting "fat binaries" out of PHP/Ruby/Python/node apps via chroot. Chroot was already well known to ops folks, but was arcane to most webapp devs.
We're not ops experts who have been confounded by marketing, we're ops amateurs for whom Docker cracked the nut of chroot legibility.
The author hates on Docker in comparison to other fat binary techniques; he ignores that pro-Docker advocates are comparing it to not using fat binaries at all.
It's a subtle distinction, because once someone is primed that these are the two options, everyone thinks they're in the second category. You have to give someone enough rope and hope they offer up how much they "love" their toys.
I like this article because the container toolset ecosystem needs criticism to evolve. And we don't see enough of it.
The article ignores the fact that companies do not have the time, money, expertise, and desire to re-write their apps in a language that will compile down into a binary. There is a reason so many successful companies use PHP and Ruby. They work and make those businesses money. Taking a golang binary and building it into a tiny scratch docker image would be fantastic too.
In a previous job we ran hundreds of bare metal machines that were built up using puppet. It was amazing in the sense that it was somewhat standardized and could scale well. I still wish every service was using docker. We had php, ruby and golang services and getting all of those dependencies running was a pain. Not only did you have specific machine images to support each language, you had to support each service type too. If they were in docker containers we could have had one machine time and moved the docker images around.
A main problem in my opinion is, that old images are no longer published (or removed from dockerhub). I doubt very much, that you can build docker images that are written now in 2030.
But I assume the same happens with Packer + Terraform. In both cases you need to make sure the image is saved and accessible at a place you control, because the build will stop working at some point in time. Also the nice thing about docker is, it runs local (developer machine) and in production. I am not sure how you archive that with AMIs.
Building fat binaries is only easy for some specific languages and tools. In docker, it is easy for everything. At the end docker gives you a standardized way to deploy (image, environment variables, network, volumes and off you go!).
Now about docker in production. I had lots of problems with that. But if you use docker for local and don't have a ops department, it is the natural way to go. You run your integration tests with the same image that later runs on prod, so you don't need to worry, what stack is running on in a different environment. As a developer with a fully automated CI chain, I can control the entire deployment from my IDE (Dockerfile, Jenkinsfile, ...). My college can review the entire deployment in the PR (code-changes and infrastructure changes). And also docker has for most external software a ready to use image. Those are big benefits for small dev teams in small companies.
Also cloud providers offer docker tooling like a private image repository and docker support in most CI tools. I mention all of this, because the tooling around a container solution is important. You may dislike docker, but it integrates in most cloud providers and has images for almost everything.
The argument about complexity is true. If something doesn't work and you have no idea about the parts under the docker layer then its game over. But this is a very general argument against complexity. Complexity in software makes everything easy until you need to go down an abstraction layer. Nobody forces you to run your MySQL or Elasticsearch in docker container. This is definitely an unnecessary (and potentially dangerous) layer of complexity.
But to run the 10 years old PHP 5 application that needs memcached version 0.1.5, docker is very very useful: you spend a week to put all that legacy stuff in an docker image, push the image and all the team members can run it locally. Even the designer that knows a bit of jquery can run "docker-compose up" on his windows machine.
But imagine what the curmudgeon of the day had to say about this. "Why do I need to use this specific container? This container has all these problems... and on and on"
Kubernetes? The jury's still out on that.
Before we used to fab-ssh into the servers, manually ask some human at softlayer to provision new servers, bash script install things, and use native package managers like pip install. Fun fact. Pip is not deterministic. Until package-lock came, npm wasn’t deterministic. Things that worked in dev and staging would end up borking prod and we’d be serving 500s. Other language package managers had similar issues.
I see docker as just a glorified package manager. Make a docker file, build an image, run the same image in prod/dev/stage for consistency.
That is a huge timesaver.