None of this is simple. We're drowning in YAML files. It's difficult to maintain. Jinja + ansible + helm... it's a joke.
There must be a better way of doing all this.
There must be a better way of doing all this.
All of this is endlessly pushed by AWS, Google, Docker, and anyone else with a foot in the "Snag as much cash from DEVs" crowd.
Other old timers will explain how they ran thousands of hits/second on 6 or 7 bare metal servers, 15 years ago, without CDNs, using LAMP, ajax/js frontends, and more. The key was code optimization, SQL queries without inane and poorly written MVC SQL logic, and the list goes on.
I am relentlessly gobsmacked at how people are spending quite literally 100 to 1000 times the cash to host on AWS, using microservices. And often amused how new devs just can't get it through their head, that yes, this is 100% factually true.
Docker replaced something that was already done ; identical PROD and DEV environments. All DEVs I had working with me, were issued VMs with 100% replicated PROD. VMs auto-build using debootstrap + SVN checkout.
Rollbacks in prod? Handled by SVN rollbacks.
When I look at the insane complexity being displayed by containers on top of VMs on top of baremetal, the MASSIVE loss in performance (yup, it's there.. especially for IO)... I just don't get it.
Many DEVs have all been sold a pack of complete and total lies.
I get called in again, and again by clients to reduce cost, optimize resource usage. I literally bring 1000x performance boosts to the SQL layer with minimal improvements.
Anyhow. Yes, this was a rant. Sorry it's a reply to you specifically.
I work in adtech (apologies). We have maybe 10 - 15 instances (16 vCPUs, 31GB RAM) that each handle 10k+ HTTP requests per second. There's a push to dockerise all this. I don't see the point.
I've often wondered about the potential performance loss of Dockerising all this, do you have public numbers available? We recently hired a ex-Googler to a management position who claims that on GCP, running docker may actually perform better than VMs. If true, that's really interesting, but I can't find anything to back it up.
Code optimisation (or even profiling) seems to be a dying art since people think that it's easier to just throw CPUs at the problem.
Docker seriously simplifies my life greatly.
If you're running Docker in a VM on a bare metal server you're doing it wrong. You should be running Docker on a bare metal server.
You're also conflating different problems here. If someone is writing poor SQL it doesn't matter if their deploying with a VM, Docker, or onto a bare metal server.
Until a bug in Docker, or the CNI abstraction, or some resource hangs/panics the kernel on the bare metal, and then you have to reboot the whole thing taking out all the containers.
This gets rarer, and rarer, as the bugs get ironed out, of course, but In my 20+ year anecdotal experience, a kernel running just a bunch of VM's crashes far less frequently than a kernel running containers.
Not if you're doing things that require certain kernel features. For example, if I have an application that uses io_uring, it's _very_ pertinent as to which kernel it runs on. A VM has that in scope, a Docker container does not.
They are explicitly not that. Docker containers do not provide you any real isolation guarantees from a security POV and make no attempts at such. This is extensively documented. [1]
"If you're running Docker in a VM on a bare metal server you're doing it wrong. "
Ummm... Running Docker inside a VM is by far the most common deployment type of Docker there is. What do you think is an EC2/ECS/GKE deployment? Hint, there's a VM running your containers in all of them. This is also what Docker the company recommends - https://www.docker.com/blog/containers-and-vms-together/
[1]: https://docs.microsoft.com/en-us/virtualization/windowsconta... https://www.redhat.com/en/topics/containers/containers-vs-vm...
They are related, as devs sometimes think of microservices as a way to speed things up and/or process more requests per second, under an assumption that a server with fewer responsibilities is a server with faster turnaround time.
- There is a lot more software being built nowadays - There are a lot more engineers working - The average age keeps decreasing to offset rising labor costs - The average skill level keeps decreasing because of increased abstraction and managed solutions (despite more information / history to learn from) - There is more B2C software running in Prod now that is "on the hook" for millions of $ of revenue
So you have more, less skilled people working on things with higher economic value. The "microservices" solution is to limit the mess and destruction they can cause by giving them their own little sandbox to build in.
Provided the "plumbing" is well enough engineered, it nets out to a better outcome than letting hundreds of 23 year old junior engineers loose on a monolith.
I expect to finish the remaining work in the next few weeks. Can I contact you to try it out? (My email is on my profile)
And based on what FunnyLookinHat mentions in another comment, Terraform seems to offer a lot less. I have no first-hand experience with Terraform to confirm that.
It has a separate state mechanism to keep things in sync that Ansible didn’t have the last time I tried only using Ansible. They’re a match made in heaven when put together IMO.
I've had a lot of success coupling Terraform with provisioners like Ansible or Saltstack.
Of course, if Ansible is what you're used to and it works for you, there's no real benefit to using something else right now :) I'm a big fan of Terraform, so I hope you also have a play around with it to see if it can help with what you're doing in the future.
Once you get your AWS account setup there's still virtually no tooling to actually manage deploys of new code into that infrastructure. We're going to hand roll some tooling on top of aws-cli most likely.
I'm already paying AWS a massive amount for compute, storage, and bandwidth - I don't want to pay more just be able to use it efficiently.
Maybe it's the FOSS nerd in me - but I can't stand the walled-gardens we're essentially creating in these IaaS providers.
(just fyi though, codedeploy is free for EC2 / lambda usages: https://aws.amazon.com/codedeploy/pricing/ )
If you're already planning on standing up at least 3 compute instances though, might as well run EKS in a cluster.
Helm uses Go templates which are awesome. It is what Hugo is built off. The main issue is that you still have to manage indentation with Helm. YAML is easier to read than JSON and TOML. If you don't like it, then what do you suggest is better?
Then you'd have your own NoCode startup generator