11–20 of 208 posts
Earlier quoted context omitted.
They are the shit tech that will be abandoned with the next fad. They are a huge boondoggle, solely for the immature leads who have not been coding for decades and know better. This industry is filled with stupid fucks that don't know tech history.
You have a point about hype, tech cycles, and solutions being pushed out of ignorance vs tech superiority if you change the language to be more civil.
Earlier quoted context omitted.
the linux world is slowly (and badly) recreating technology that has existed in FreeBSD and Solaris/Illumos for decades.
Which technologies were those? I’m only vaguely familiar with FreeBSD, and not at all with Solaris.
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 igno…
They are the shit tech that will be abandoned with the next fad. They are a huge boondoggle, solely for the immature leads who have not been coding for decades and know better. This industry is filled with stupid fucks that don't know tech history.
Earlier quoted context omitted.
They are the shit tech that will be abandoned with the next fad. They are a huge boondoggle, solely for the immature leads who have not been coding for decades and know better. This industry is filled with stupid fucks that don't know tech history.
You have a point about hype, tech cycles, and solutions being pushed out of ignorance vs tech superiority if you change the language to be more civil.
Earlier quoted context omitted.
You have a point about hype, tech cycles, and solutions being pushed out of ignorance vs tech superiority if you change the language to be more civil.
Although it's a bad point without any concrete examples. Without that, it just seems like a baseless emotional reaction to not liking something new. I might even be inclined to agree if there was a bit more detail given.
Disclaimer: Infra/DevOps engineer previously, 20 years total in tech
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.
edit: btw, I'm one of those (former) neckbeards...
Earlier quoted context omitted.
They are the shit tech that will be abandoned with the next fad. They are a huge boondoggle, solely for the immature leads who have not been coding for decades and know better. This industry is filled with stupid fucks that don't know tech history.
You have a point about hype, tech cycles, and solutions being pushed out of ignorance vs tech superiority if you change the language to be more civil.
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 igno…
The economics are interesting though. Computing resources are super cheap and getting more cheap everyday. (Well except for RAM!) The waste produced by containers means says, yeah, give each application its own app server. Its own web server, its own JDBC driver, even its own JDK. We'll throw it all on the cloud and run it for a few cents each hour.
The problem is that testing isn't cheap. This is where microservices and containers and the all this craziness will fall down. Now you've got dozens and dozens of applications all running with their own application servers, JDBC drivers, and their own JDK. This is a combinatoric explosion in your testing surface.
The true value of the application server approach is that it forced applications to conform to a clear contract. Once your application conformed to this contract it could be thrown over the wall into a full-time ops organization that could transparently deploy, monitor and manage the app.
The container madness will come to an end. People will realize that giving developers the keys to the kingdom and total freedom over their application is a terrible idea. (And smart developers don't want total freedom.) What will emerge will be something much more interesting: a hybrid approach where applications can be bundled into into artifacts that fully express their dependencies and containers can be annotated in a way that fully express their capabilities.
Containers provide isolation and immutable infrastructure and this is good. Appservers provide standardization, specialization and separation of responsibilities and this is also good. There's no reason why we can't enjoy both.
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 igno…