That can be true if you are using tightly coupled event sources (like s3, SNS, etc) where you need to inspect the incoming object. If you are doing a HTTP / REST API, try to decouple the code as much as possible from the API Gateway invocation by using ExpressJS / aws-serverless-express to aid in local testing and debugging. Then testing and debugging locally becomes much easier.
This is my preferred style, and since an express app is technically just a function that accepts req/res, you can pass a whole express app in as the function when running in the cloud, so you have multiple path routes, middleware, the whole nine. You can actually host a fairly complex API in a single function subject to the package size/dependency count restrictions of your FaaS of choice
Problem is, meat won't take on any smoke ring after a certain temperature (170 degrees)[1]. Thus you won't get that beautiful authentic smoked meat ring if you precook without smoke. To some, you may as well cook it in the microwave if it ain't got a smoke ring.
I have a cluster of raspberry Pis setup next to my SmartThings hub. I upgraded storage to use external SSDs via USB 3.0 cables. After that, all my ZigBee devices dropped communication with my hub. After some troubleshooting, I just moved my hub to a different room.
Docker Swarm usage here in production. Mainly a regulatory and compliance constraint, but it is relatively simple compared to other container orchestration platforms.
This was a hilarious clip. Brought me back to 15 years ago, messing around with people on Ventrilo while playing World of Warcraft. Many, many lost nights and days playing that addictive game. Comic relief thru Ventrilo harassment was necessary...
Docker most definitely has ARM and multi-architecture support. That is, assuming the particular image you are attempting to pull has been published using the Manifest V2 spec and has ARM images published. The issue you mention is an issue with the image publisher/maintainer not Docker itself.
I maintain a number of Docker images that have multiarch support (as seen in the Tags view on DockerHub:
This isn't an accurate statement. I work on behalf of a federal government agency, and no one has write access in development, let alone production. Everything is required to run thru our ci/cd pipeline. Times are changing.
For the better? I’m not asking out of preference, I’m asking out of actual conclusion: is trading the operational overhead of running LDAP for a usually homegrown, usually wobbly automated scripting soufflé that turns Make into a distributed system objectively better? Has nobody stopped to ask, is DevOps and CI/CD the best framework we can achieve? Did nobody think to ask before they told your agency it was the ‘right’ methodology and the objectively best way to build industrial, business process software in the government sector? Did the changing times come from ideology and belief or identified process gaps?
I ask because I think there’s something better. I don’t know what it is yet, but I want to find out. I’m worried about wastage in DevOps methodologies, a system where nobody is incentivized to care about the right things, going on to spook the policymakers on doing software before we find out if the DevOps and Cloud worlds, both, are objectively the best way to do software for their purposes. I strongly, strongly feel like the craft is on the wrong path, and persuasive successes in industry are getting to the right ears before we know if the discipline to efficiently handle agile infrastructure with today’s tooling is even possible. I’m not convinced DevOps will organically find the right calculus to spur the kind of systems research that took us to not only where we are, but that which will take us where we need to go.
Speaking of, I’m lazily glancing at Agile here as well but I’m not prepared for a coherent argument there, beyond pointing out that we now have better tooling for managing specifications, particularly formal and mathematical ones, than the waterfall development experiences that prompted agile thinking. We need more systems research, tinkering, rethinking POSIX, all of it.
Imagine a Graph,
the x-axis is time or adoption of a set of technologies.
Right now the hump in the bell curve is CI/CD and devops. It's safe to be in a large group.
If something better comes along then it'll start happening and in 15 years I expect the whole of government to adopt it when you are bemoaning the pitfalls of any new approach.
I know what a hype curve is, and I made two substantive points to differentiate this situation from a hype curve. I’m not “bemoaning the pitfalls,” I’ll repeat that I’m concerned this approach, which is gaining traction and getting solidified and entrenched, will spook the decisionmakers on being willing to accept your 15-year solution when it comes along.
If you’re going to be as patronizing as you are, please at least read what I’ve written and respond to it.
CI/CD is a good enough framework at the moment.
The goal is to build things and ship product to customers. It does that well and thats why it's winning.
The fact that a jenkinsfile starts with groovy and can include N number of different languages is just the nature of the beast. There is always fragmentation in software integration, and devops is integration on steroids.
Any other methods, formal or otherwise, need to provide X value at a cost of Y that makes adoption worth it. Currently if you don't use CI/CD then the value and cost propositions of adopting CI/CD actually start to make a lot of sense if you are mature enough to accurately do cost accounting on your IT management processes.
Yes, it's true, Jenkinsfiles, Cloudformation Json and Yaml all suck to work with. And configuration management is tricky. But I know that we'll all think the same thing about any other system or approach we adopt because it'll end up being work.
CI/CD may be a trade off but it allows us to focus on business problems rather than technical ones.
I dont disagree with many of your points, but are you advocating "logging into a production system and editing the config file in nano"? Can't tell if you are...
