I code a little but largely on the periphery of stuff so as to not be in the critical path. I try to fix small bugs snd keep up with the code base but with nine reports I've got much other work to do.
Anyone who thought we would seriously defend Taiwan is a fool. Middle America routinely makes fun of Asian people, you think they're gonna be happy to send their kids to die for them?
Counterpoint they literally already did that and we weren’t less racist in the 60s and 70s. Personally I don’t think Trump would defend Taiwan but I object to such a disregard of history.
I ditched Terraform years ago and just interact with the raw cloud provider SDKs now. It's much easier to long-term evolve actual code and deal with weird edgecases that come up when you're not in beholden to the straight jacket that is configuration masquerading as code.
Oh yea, and we can write tests for all that provisioning logic too.
I went through the same evolution, even built a PaaS for AWS, but I kept going and now just deploy my own stuff to VMs with Swarm via one command in Rove. It's great. And yes I know kubernetes I use it at work. It's an unnecessary waste of time.
docker swarm is so simple and easy compared to the utter behemoth that is k8s, and basically is all you need for CRUD webapps 80-90% of the time. add an RDS instance and you’re set.
i will always pick swarm in a small company* whenever possible until k8s or ECS makes sense because something has changed and it’s needed.
Not OP, but for rolling back we just… revert the change to the setup_k8s_stuff.py script
!
In practice it’s a module that integrates with quite a large number of things in the monolith because that’s one of the advantages of Infrastructure as Actual Code: symbols and enums and functions that have meaningful semantics in your business logic are frequently useful in your infrastructure logic too. The Apples API runs on the Apples tier, the Oranges API runs on the Oranges tier, etc. etc.
People call me old fashioned (“it’s not the 1990s any more”) but when I deploy something it’s a brand new set of instances to which traffic gets migrated. We don’t modify in place with anything clever and I imagine reverting changes in a mutable environment is indeed quite hard to get right (and what you are hinting at?)
One thing that annoys me is the inconsistency between mutable "data" resources and everything else.
Something that would be nice would be the rough equivalent of the deployment slots used in Azure App Service, but for everything else too. So you could provision a "whole new resource" and then atomically switch traffic over to it.
You can express this in Terraform, it's just a little more contrived. You release your changes as Terraform modules (a module in and of itself doesn't do anything, it's like a library/package), then your Terraform workspace instantiates both a "blue" module and a "green" module, at different versions, with DNS / load balancing resources depending on both modules and switching between either blue or green.
I’ve been thinking about this for a long time. But doesn’t it brings a host of other issues? For example, I need to update instance RAM from 4 to 8 Gb but how do I know if the instance exists or should be created? I need to make a small change, how do I know what parts of my scripts to run?
> For example, I need to update instance RAM from 4 to 8 Gb but how do I know if the instance exists or should be created?
let front_id = if instance_exists("front_balancer") {
return fetch_instance("front_balancer").id
} else {
return create_new_instance("front_balancer", front_balancer_opts).id
}
Or however else you would manage that sort of thing in your favorite programming language.
> I need to make a small change, how do I know what parts of my scripts to run?
Either just re-run the parts you know you've changed (manually or based on git diffs), or even better, make the entire thing idempotent and you won't have to care, re-run the entire program after each change and it'll automagically work.
> Either just re-run the parts you know you've changed (manually or based on git diffs)
This is exactly the sort of thing Terraform is designed to avoid because it can obviously get quite messy. Agreed that making things idempotent solves that problem, but it's not always obvious/easy how to do so.
I get the idea but I don't think it addresses the issue. There has to be a function that a) checks if instance exists b) checks if instance state is what I want (e.g. it has 8 GB ram) c) if not it updates the instance. Ideally it also locks environment while doing this to prevent race conditions. It can be written but seems to be quite cumbersome. Complexity of this code and also time it takes to run it what concerns me most.
I guess this is why terraform state is there. IMHO state is IaaC biggest weakness because you have to keep it consistent with actual cloud state. If we can just query state from the cloud and make it performant + be able to automatically (or just fast enough) select resources to be update it would be ideal.
You write code to do these things? If there's a requirement for you to be able to do such a thing make it a feature, implement it with tests and voila, no different than any other feature or bug you work on is it?
Here are the things that TF does that you are probably not going to get around to in a comprehensive way-
- State tracking, especially all of the tedious per cloud resource details
- Parallelism- TF defaults to 10 threads at a time. You won't notice this when you write a demo to deploy one thing, but it really matters as you accrete more things.
- Dependency tracking- hand in hand with the parallelism, but this is what makes it possible. It is tedious, resource by resource blood sweat and tears stuff, and enabled by the inexpressive nature of HCL
Plus, you know, all of the work that has already done by other people to wrap a million quirky APIs in a uniform way.
Exactly. You tried your best but powerful shadow powers worked against you so you need even more power to fight them. And you know it may sound bad but things have to get worse before they get better. The population has to bear with you for just a bit more and you assure them you won't abuse any powers given to you, and if you do, it's because you were forced to.
It's election day, you get re-elected, rinse and repeat until the next generation has no memory of it ever being different.
I was in nearly the sweet spot for this in school computer labs as a kid so it felt like a long time to me. They only started to get boring looking when I graduated from high school.
I'm kinda split between it and the original G3 range (slot loading preferably, but in the original bright transparent colours before it got weird with stuff like "blue Dalmatian"). The anglepoise Mac is kinda near beginning of the rather sterile Apple aesthetic that has never gone away, but it's also incredibly neat in a packaging sense that a CRT could never be. I kinda want a combination, but I'm not sure if you could get away with the colour bits on an all-in-one without the large area needed for the CRT neck...
The Blue and White PowerMac G3 is my ultimate best looking Mac, there's something about the giant G3 on the sides, and the bold colours for what is a "professional" system. Sadly it all got toned down for the G4...
The G3 were cool in a different way. I miss the playful coloring of late 90s devices. Computers grew up but did we also need our game consoles to become soulless rip offs of Apple industrial design?
Edit: I want a translucent atomic purple phone damnit!
It was late 90s / early 2000s specifically, right? N64 was colorful, GameCube a bit less, but not the SNES, Genesis, NES, etc. Kinda the same with the Mac GUIs.
As a owner of both slot load and tray load G3's, I strongly prefer the tray loaders. The drives still work, while I have to jam a credit card with double-sided tape into the drive to get a disc out of the slot load drive.
Yeah, I have two of the G4's and while they are really nice, I'd love a PowerMac G3 sometime. I have G5's as well, and again they are cool, but not in the way the G3 was -- just so striking and IMO creativity-inspiring.
C++ is almost nowhere to be seen in modern day distributed computing and business software, outside OS, language runtimes, databases and networking stacks, also known as low level infrastructure code.
All relevant application software is written mainly in a mix of Java and .NET languages, complemented with a mix Go, Rust, Python, Ruby, and SQL dialects.
Likewise Apple, Google and Microsoft no longer have C++ based GUI frameworks, like it was common in the 1990's, and one of them ships a whole OS where Java rules the userspace.
It did to a degree but still left a sizeable amount of use cases as they were ill suited for Java. I feel like this is repeatedly happened since where each new or newly hyper language has peeled off parts of C++'s use cases but never gone for the core. I feel like Rust is the first that can do it and significantly improve on it. While it does lack specialization and some template tricks, it has memory safety, core/alloc/std, first and third party libraries focusing on `Result` rather than exceptions, etc. This is much better suited for kernel, embedded, and framework development while also being able to scale up into the use cases that went to Java and other languages previously.
Given that MSFT seemingly failed to extend-and-then-extinguish Java, what is the applicability of this analogy?
(I don't have any particular faith in MSFT. I just don't think EEE even remotely works as a strategy in cases like this, and I think MSFT is not stupid enough to think that it does.)
Just like Google did with Android, which apparently gets celebrated in FOSS circles, big bad Oracle, what they think they are playing the Sun lawsuit card.
You don't understand, those people were brown and the wrong religion and were easily associated with the other brown guys that killed a couple thousand people in 2001.
Also 4K is a drop in the bucket compared to what it would take to defend Taiwan.
reply