381–390 of 536 posts
"Why don’t I just use Google’s thing? "-You think that’s going to be around in 6 months?" Isn't reputation a thing of beauty?
Earlier quoted context omitted.
Shell does things well provided all the intermediate states are naturally expressible as streams of bytes. Otherwise not so much. I think the advantages of using a single language for everything outweigh the disadvantages - see e.g. http://www.teamten.com/lawrence/writings/java-for-everything... (though actually my single language is Scala)
Everything in a computer is a stream of bytes... My shell scripts often use tools like jq and jshon to deal with JSON structures, etc. File hierarchies can also be very pleasant data structures. The kinds of scripts I write would be awkward to have as compiled JVM programs, I think. Shell is just way more ergonomic for me for many tasks.
Data can be meaningfully separated from control and structure in many cases, and failure to do that is a major (perhaps the major) source of security bugs.
Earlier quoted context omitted.
Namespaced filesystem and networking, just for one. you seem very eager to dismiss a technology you only barely understand.
Namespaced filesystem shouldn't even be a special requirement - your program should use relative or at least configurable paths. I mean, directories are namespaced filesystems. What networking problems does Docker solve?
Your program don't see what else is running on the system. Also means that it removes possible conflicts for shared libraries and other system-wide dependencies.
This kind of isolation is not only good for app bundling as a developer, but even more important as an operator in a multi-tenant scenario. You throw in containers and they don't step on each other toes. Plus, system stay clean and it's easy to move things around.
Network namespace as in linux network namespace (http://man7.org/linux/man-pages/man8/ip-netns.8.html).
Each container has it's own IP stack.
Containers provide proper abstractions so you can then assemble all of this, pretty much like you use pipes on a unix shell.
Earlier quoted context omitted.
> Any positive experiences with micro-services here? Yep. We already had a feature flag system, a minimal monitoring system, and a robust alerting system in place. Microservices make our deployments much more granular. No longer do we have to roll back perfectly good changes because of bugs in unrelated parts of the codebase. Before, we had to have involved conversations about deployments, and there were many things…
How granular are your services? I've heard a lot of talk about microservices without much talk about how micro they are. As someone who's happy with the approach, would you mind giving a little context in terms of what sort of degree you've split the system down?
To be honest, we still have a monolithic application at the heart of our system that we've been slow to decompose, though we're working on it. We deploy it on a regular cadence and use feature flags heavily to make it play nice with everything else.
"-No, look into microservices. It’s the future. It’s how we do everything now. You take your monolithic app and you split it into like 12 services. One for each job you do. That seems excessive" A 100 times yes. We tried to split our monolithic Rails app into micro-services built in Go. 2 years and many fires later, we decided to abandon the project. It was mostly because the monitoring and alerting were now split in…
I think that splitting into micro services is valuable if and only if you reach a scale where it makes sense to split into micro services. By scale, I mean the number of people on the team (if you have a lot of people, it can make sense to split into micro-services to limit communication bottlenecks between developers) or in term of traffic, in which case microservices can be very useful to better optimize the system…
That's a good point. I think this thought extrapolates to other parts of software engineering as well. Sometimes writing very modular and decoupled software from the beginning is very hard for a small team, and we can't see well if this is the best approach since it's also hard to grasp the big picture.
I'm currently facing this issue. I'm trying to write very modular and reusable applications, but now I'm paralyzed trying to picture the best patterns to use, where should I use a facade, a decorator, etc. I think I'll adopt this strategy for myself--only focus on modularizing from the beginning if it'd lead to extra work otherwise.
Earlier quoted context omitted.
I worry when I can't tell if a comment like this is based on fact or just trying to be funny. Because I've seen my share of nasty "legacy" automation but, surprisingly, I still think a good set of well thought-out shell scripts written by someone that understands what's being automated still beat modern tools, even when the person doing the automation is the same. I don't quite know why this is, but there's something…
An un-researched opinion from someone who replaced chef/ansible/puppet with his own shell-script config-management system: I don't have to rewrite my shell-scripts every 6 months when a new version comes out. New updates usually only happen when security issues arise. Shell-scripts tend to be simple. There's not a lot of magic hand-holding going on, which means not a lot of complexity to break things. It keeps you fr…
This applies to small environments. If the environment is large the situation almost reverses.
Deploying automation throughout a large homogenous environment is where config-management tools really shine. They make it easy to ensure homogeneity is maintained (even if that just means ensuring all machines have the same set of shell scripts) and allow grouping for staggered updates.
If the environment is widely-ranged and large, the utopia starts to break down. Their configuration explodes in complexity and (if you're not careful) you end up with mostly the same amount of work as if they were managed as small independent environments. With the added risk that there is now a single place from where you can break everything at once.
And this happens... Usually from wrong assumptions of what's common between all machines in the environment. In homogeneous environments almost everything is common, but in widely-ranged environments you sometimes add some configuration that wasn't there before and you think applies to the whole set and all hell breaks loose. If you're lucky this will happen suddenly, if you're not, breakage will spread slowly and you'll spend quite a lot of time scratching your head on why.
As the author of that "Docker is the Heroku Killer" post that was popular a couple of years ago I have to say that I agree with this. When I wrote that article it was largely focused on the potential for Docker to create a bunch of Heroku competitors as well as a simplified development experience across multiple languages. The businesses aren't there yet although a ton are trying. The local dev experience has not mat…
I'm working on one of those Docker powered Heroku "competitors". This post and your post both rung true for me. It's a constant balancing act. Too flexible, it becomes overwhelming. Too constrained and you sacrifice a bunch of the perks of using Docker. The conclusion I've come to is the only way to do it is to be unashamedly opinionated about keeping things simple for the average user. Otherwise you end up having th…
Earlier quoted context omitted.
I never thought I would appreciate Java...but the industry has really made me. Take your .war file, drop it onto JBoss. It deploys across the cluster in a zero downtime manner, isolates configuration, provides consistent log structure, cert management, deployment. You can deploy dozens of small war's to the same server and they can talk to each other. Load balance across the cluster automatically based on actual load…
Can you do similar stuff with clojure or Scala? Maybe there's a way to avoid the bad parts