131–140 of 202 posts
Earlier quoted context omitted.
Using real person-related data for testing was made illegal in Europe by GDPR. Even with explicit consent of each affected person, the tester needs to make sure that the test really requires real person-related data, otherwise it would violate the principle of "privacy by design" from GDPR. Without consent it is entirely forbidden, as of my understanding of the GDPR. Due to GDPR I had to implement an anonymization fe…
[deleted]
There will not be a massive productivity boost in the next 10 years. We haven't had a productivity boost in the past 20 years. In fact, we're much less productive now. But I digress. We're still largely making and running software the same way we did 20 years ago. The only major differences are the principles that underpin the most modern best practices. "What the fuck does that mean," you say? It means that I can ta…
I wonder what you think is the alternative to Kubernetes that makes it easier to deploy a piece of code to run on a cluster. I hope it's not some kludge of cobbled together shell scripts and ssh. In general these ideas of magical 'immutable' infrastructures seem to pan out much worse than just plain VMs with some orchestration solution inside. Anything that tries to capture the state of the world and reify it usually…
Immutable Infrastructure isn't magical at all, it's a paradigm shift which has real world effects. And you can do it with plain VMs and some software inside. But the VM has to be immutable, and the software inside should be as immutable as possible. Otherwise you are constantly fighting a battle to "fix" the state over and over again, and you can't clearly reason about the operation of the system.
Immutable Infrastructure doesn't solve the halting problem, it avoids the halting problem, because it depends on not having general algorithms and unlimited input. It instead uses specific operations with specific criteria in a predictable way, the way safety systems are designed.
The desire to go "truly serverless" and pretend the computer does not actually exist is absolutely delusional. The refusal to acknowledge that software will never be anything beyond executable data on some kind of computer, somewhere, is why most web-based software is so slow and shitty. Having someone build the server and assign your code to run on it does not change that one (pun intended) bit.
...but with a locked-in contract with one taxi company. And less privacy.
Unsurprisingly, in the long term, it will cost you more.
Earlier quoted context omitted.
What do people like about NAT? I am guessing that the perceived increase in security. But perhaps there are more real or perceived advantages.
At home I really appreciate the NAT. I'm glad not every device has a public IP and gets hammered with attacks 24/7. It's not fail-safe but it definitely adds some security.. As for cloud, no idea what the benefit should be there.
Virtualization eventually will be seen as the unnecessary layer added to make up for operating systems that lack capability based security. It's going to take a decade to refactor things to remove that layer. Once done, you'll be able to safely run a process against a list of resources.
Virtualization eventually will be seen as the unnecessary layer added to make up for operating systems that lack capability based security. It's going to take a decade to refactor things to remove that layer. Once done, you'll be able to safely run a process against a list of resources.
Agreed. Operating systems abstract resources, the fact that we needed containers and VMs point to the fact that the first set of implementations weren't optimal and needs to be refactored. For VMs, security is the one concern, the others would be more direct access to lower levels and greater access to the hardware and internals than just a driver model. For containers I'd say that the abstraction/interface presented…
Projects similar to this exist today with https://nanos.org/.
You can run any typical web app (without having to re-write it) in a POSIX compliant Unikernel on most major cloud providers and bare metal. Each service runs in its own Unikernel.
I had its creator on my podcast the other day at: https://runninginproduction.com/podcast/79-nanovms-let-you-r...
There will not be a massive productivity boost in the next 10 years. We haven't had a productivity boost in the past 20 years. In fact, we're much less productive now. But I digress. We're still largely making and running software the same way we did 20 years ago. The only major differences are the principles that underpin the most modern best practices. "What the fuck does that mean," you say? It means that I can ta…
Keep your s3 config in version control, terraform apply, if it doesn't work revert the commit and terraform apply again. The DSL isn't that hard: https://registry.terraform.io/providers/hashicorp/aws/latest...
What happens if your network is interrupted during apply or your STS credential expires? If you are lucky, you may be able to upload the errored.tfstate and plan/apply again. But if somebody else plan/applies before then, the state will be out of whack. Resources will already exist with names that you want to use, and you will have to manually edit the state file, or import the existing resources, or delete them.
What happens if someone changes the bucket without using Terraform? The bucket's changes are blown away on the next terraform apply. Or the apply will sometimes just fail, and you'll have to fix the state or resource by hand.
What happens if someone has applied a different change after your change? Reverting the commit may now impact something else somebody since removed/added, running into naming conflicts and needing custom code changes, and sometimes moving around of state (happens often when a commit changes whole modules).
Or say a code change changes the provider version. A revert may not work and you may need to remediate the infra and code yet again.
Or say someone applied Terraform with a newer version of Terraform. Now you need to upgrade your version of Terraform, and change whatever code you wanted to revert to the new Terraform version.
Or say the resource + action require delete before create, and your reverted commit tries to do create before delete. You'll need to modify your Terraform code after reverting it with a new lifecycle block, or apply will keep trying to do something impossible.
All of this is happening in production. How much downtime is ok while you fix all of those problems by hand?
Earlier quoted context omitted.
Your comment makes me realize how lucky I am at my job: we do this production environment replication via “SAN magic” and it is so insanely useful.
How do you deal with replicating customer data / data the developer / tester should not have access to? Do you copy that into the ephemeral test environment as well? How are permissions managd for accessing that data? Does it have the same restrictions as in prod? (i.e. even in this env the developer / tester has no access to systems / data they would not have in prod).
In Security this is known as "fuzzing", but instead of looking for security vulnerabilities, you're generating test data for databases. Your test data should cover all possible customer data inputs. Then you not only don't need real customer data for testing, you catch bugs before a customer does.
There will not be a massive productivity boost in the next 10 years. We haven't had a productivity boost in the past 20 years. In fact, we're much less productive now. But I digress. We're still largely making and running software the same way we did 20 years ago. The only major differences are the principles that underpin the most modern best practices. "What the fuck does that mean," you say? It means that I can ta…
Citation needed. Run _with a plan_, terraform apply is entirely predictable as to the operations it will carry out and the order in which it will carry them out.
There will not be a massive productivity boost in the next 10 years. We haven't had a productivity boost in the past 20 years. In fact, we're much less productive now. But I digress. We're still largely making and running software the same way we did 20 years ago. The only major differences are the principles that underpin the most modern best practices. "What the fuck does that mean," you say? It means that I can ta…
> running terraform apply is unpredictable, due to the nature of the design of the program, even though it was created with the opposite intention Citation needed. Run _with a plan_, terraform apply is entirely predictable as to the operations it will carry out and the order in which it will carry them out.
First of all, what does terraform apply do? It runs API calls. Those API calls may or may not work, based on criteria outside of the control of Terraform. It may be supposed to work, but that doesn't mean it will. Use AWS enough and you will run into this weekly.
Second, Terraform has semantics to do things like "create before delete" or "delete before create". This behavior is controlled by the provider, per-resource. But Terraform has no earthly fucking clue which it's supposed to do, only the provider knows. And the provider does not check before terraform apply runs whether an operation will conflict with a resource, even if Terraform is managing that resource.
So you run terraform plan -out=terraform.plan, and the whole thing output seems fine! So you terraform apply terraform.plan, and Terraform happily performs an operation which is literally impossible, and then fails. Then you go find the code that has been working just fine for 2 years and change it to fix the lifecycle for this particular scenario, and then you can terraform apply correctly.
Thirdly, a lot of terraform plan runs show output with unknown values, because the values won't be known until after you run terraform apply. But those values can conflict with existing resources with the same values. Terraform makes no attempt to verify if conflicting resources exist before apply. Therefore, your terraform apply can fail unpredictably (to be correct: you could predict it if Terraform were designed to actually look for conflicting resources before applying).
There's about a hundred of these edge cases that I run into every day. I already perform all operations in a non-production environment, but as we all know, the environments naturally drift (because cloud infrastructure is mutable infrastructure) so there are times production breaks in a way that didn't in non-production.