> Maybe AWS should put their dashboards on GCP
Then the status page would be almost entirely useless ...
96 karma · joined January 4, 2018
Then the status page would be almost entirely useless ...
There's most likely a reason for this.
Like, maybe in the past AWS customers have tried claiming for SLA credits for incidents that didn't impact them, in order to reduce their bill.
> You'd think they would have learned from that.
They did.
The page has been updated numerous times since the start of this incident.
You imply that Amazon/AWS doesn't employ any staff in the UK, which is wrong.
> Amazon will not pay any tax within the UK
Amazon must certainly pay taxes in the UK, or at least the tax ends up being paid on Amazon share price increases from employees share vesting.
Why would you build exactly the same setup in AWS as for on-prem, unless your objective is to (dishonestly) show that on-prem is cheaper?
Lift-and-shift-to-the-cloud is known to be more expensive, because you aren't taking advantage of the features available to you which would allow you to reduce your costs.
Your results (e.g. that z1d.xlarge with 4 vCPUs is only 10% slower than z1d.2xlarge with 8 vCPUs) shows that the "performance" you were testing was disk IO throughput (probably dominated by disk latency), not vCPUs.
> My takeaways were that many cloud provider offerings make no sense whatsoever, and that Xeon processors are mostly great if you are a cloud provider and want to offer overbooked "vCPUs".
> I haven't tested those specific setups, but I strongly suspect a dedicated server from OVH is much faster than a 4.16xlarge from AWS.
You seem to be implying that AWS/EC2 does CPU over-provisioning on all instance types; this is incorrect, only T-family instance types use CPU over-provisioning.
Not necessarily.
It could very easily be done via IP address matching (think BGP communities that advertise specific subnets between one part of a network and another, as are typically used for optimal CDN routing etc.).
In my country, our anti-ISP media claims that we have the most expensive internet in the world, but 10/5Mbps FTTH (in most cases with free upgrades to 20/2Mbps for the duration of COVID-19 WFH guidance mandated by the government) is quite commonly available at < $20-$25/month, and where it isn't, 10/1Mbps ADSL is available for $25-$30/month (including POTS voice service).
Thus, it is impossible that you, in the country of ~$20 1Gbps service, have worse and more expensive service.
</sarcasm>
> We need more choices for our ISPs
If you fix this, e.g. by requiring all last-mile owners to offer the last-mile access at or below their (audited, sufficiently-profitable) input cost to their retail products, most of the remaining problems would sort themselves out, without having micro-managing of ISP features.
Unless you are going to start regulating OTTs in what features/value they can provide, I think it's unfair on (non-monopoly) ISPs to prevent them from providing innovative features because of "net neutrality should trump all" opinions.
> If you are using Bash and you have the option of using ZSH, you should switch to it. ZSH has additional auto-complete and history features that Bash doesn’t have (but don't worry - those features will not be relevant to this tutorial.)
oh-my-zsh seems to be recommended by a lot of developers in this company, even though: * the default mechanism to install is curl|sh (there is no Homebrew package) on developer machines which have privileged access to a lot of resources * installing it via its recommended installation procedure on dev machines would violate company policies, whereas installing bash-completion wouldn't
I have noticed that a lot of the features listed in https://www.gnu.org/software/bash/manual/bash.html#Major-Dif... aren't present in zsh, but I am not sure of all the ones that aren't in zsh.
Ones that I have used in bash that aren't in zsh (there may be many more, I stopped using zsh in many scenarios because of some of these):
* Some of https://www.gnu.org/software/bash/manual/bash.html#Shell-Par... (e.g at least ${LOGNAME^^}, `(FOO=BAR;echo ${FOO,,})`)
* -p option to read for the prompt, e.g. `read -s -p "Enter the DB password: " PW`
As does bash-completion, which is available in many (but not all :-/) Linux distros and via Homebrew on MacOS and [pre-dates](https://github.com/scop/bash-completion/tree/09b07d57a7031d9...) [oh-my-zsh](https://github.com/ohmyzsh/ohmyzsh/tree/5da20b9dddb1f7a91106...) by about 6 years.
But, zsh users and oh-my-zsh fan-boys seem to be entirely ignorant of bash-completion.
Or just use zim ( https://zim-wiki.org/ ) which allows you to embed graphviz diagrams in any 'page', and many other features.
The "massive enterprise company" I work for doesn't use Oracle IdM ...
It was used at the previous company I worked for, but it had endless problems and I think it was only bought as part of a very badly-run "buy an expensive 'enterprise content management platform and then not use it properly' initiative".
It's main feature seemed to be to import identities from LDAP servers into an Oracle database fronted by a very poorly performing non-compliant LDAP server (or, you could say, selling Oracle Database licenses).
So they don't seem to be very serious about multi-tenancy?
(Spectre and Meltdown are more or less considered the nails in the coffin of Xen para-virtualisation for multi-tenant environments).
Was this some time ago?
The FAQ for ACM (https://aws.amazon.com/certificate-manager/faqs/ ) says:
> Q: When does ACM renew certificates? > > ACM begins the renewal process up to 60 days prior to the certificate’s expiration date. The validity period for ACM certificates is currently 13 months. Refer to the ACM User Guide for more information about managed renewal.
> We switched TLS termination from the load balancer to Envoy + cert-manager and the results were much better. You also get HTTP/2 out of the deal. We also wrote a thing that fetches every https host and makes sure the certificate works, and fed the expiration times in prometheus to actually be alerted when rotation is broken. Both are features Amazon should support out of the box for the $20/month + $$/gigabyte you pay them for a TLS-terminating load balancer.
You're implying that AWS doesn't support HTTP/2 on any load-balancers they offer, but ALB has supported HTTP/2 since launch ( https://aws.amazon.com/blogs/aws/new-aws-application-load-ba... ) 3 years ago.
I don't see any current load-balancer priced at $20/month (ALB, NLB and Classic ELB are all ~ $8/month), so I can't guess which one you were using here ...
> Instead, I'd compare e2-std-2 to m5.large like you started to do so.
Yes, a "baseline performance" of 100% would more or less be an M-family instance, but with additional overhead to manage noisy neighbors etc. (and thus T-family is slightly more expensive for the same constant performance than M-family). T-family is specifically for non-constant workloads where CPU over-commit provides value, but without memory over-commit, which can result in highly-variable performance.
Neither T-family or M-family do "memory stealing" aka memory overcommit, like GCP's E2 seemingly does (but the pricing page doesn't explicitly state this, and your detailed comparisons omit this crucial difference).
So, apples and oranges; you shouldn't really "compare" without benchmarking ...
What is the "baseline" memory GCP E2 instances get?
And has been possible on KVM (e.g. VirtManager, RHV/RHEV/Ovirt) for years too.
Xen 3 also supported online memory increases (but I don't think CPU).
Based on what evidence? Statements from Google that AWS doesn't do live migration?
You're implying here that EC2 doesn't do this.
On what basis?
How does provide visibility into every dependency inside an image? Especially when using 3rd-party-maintained images that consist of significant hours of work per image to get the image to work.
(BTW., I built "live CD images" for use in physical and virtual machines since ~2001, using tools such as mklivecd, livecd-tools etc.).
How were you launching? Using EC2 directly (e.g. `aws ec2` cli or RunInstances API call - https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_R... ), or using e.g. ASGs?
If you were launching directly with EC2, were you doing targeted launches (e.g. specifying Placement.AvailabilityZone for classic or SubnetId for VPC)?
In the case of an AZ failure, launches which don't specify an AvailabilityZone or SubnetId may be impacted for a few minutes, whereas launches which do specify them should still succeed.
That's totally not the case, all the previous solutions were slightly broken (pam_console, ConsoleKit etc.), and unmaintained.
> For the record, my largest gripe with systemd is systemd-resolved too
So, uninstall it. It's not a part of systemd (the daemon), and totally optional.
Sure, but there is nothing inherent about a text editor or desktop environment that results in you only being able to support one at a time.
It is only practical to run one system initialisation daemon on one system image at a time (unless your system initialisation daemon is too broken to support all the requirements, e.g. if you find yourself running daemontools on sysvinit).
Duplication for the sake of duplication that benefits no-one is just a waste of resources that could be spent on improving other parts of the ecosystem (addressing some of the other gripes the author has).
> There are any number of major security vulnerabilities, but that's not really the point.
There are only about 2 in systemd itself.
> There are any number of major security vulnerabilities, but that's not really the point.
systemd has fewer CVEs than the default syslog implementation used on most distros before systemd (rsyslog), but of course you knew I was referring to open bug reports, not resolved ones.
> to a non-standardised binary logging daemon
There are pros and cons to this. I would prefer to be able to dispense with journald in some situations, but in many cases it is very convenient to have, and it solves problems that no Unix system had completely solved before it.
> Most of the really obnoxious things systemd does are by design so there are no bug reports. Tight coupling to kernel and udev versions
When tight coupling is done by the BSDs, it is considered a good thing, when systemd uses features that don't exist on the BSDs, suddenly that's a bad thing ...
> to a custom DNS implementation...
While a custom DNS resolver is provided as part of the systemd source, which has some advantages, it is by no means a requirement, and it a totally separate service/binary. Many distros don't install it by default (yet).
As far as I know, on most BSDs, unless you happen to have a complete source tree snapshot for said system (becoming more difficult to maintain if you build multiple systems without special tricks to retain binary artifacts), you're out of luck, you'll get today's STABLE or RELEASE, not the one from 17 days ago when your current production box was built that works perfectly unlike the one today that is broken.
This is trivial to accomplish on all Linux distros.
(I would say this kind of issue should be listed in the table in the article).
As far as I can tell (not actually using Debian or Ubuntu myself), there was only a debacle in Debian and Ubuntu, because they took too long to decide, and ended up having to rush their migration.
All the other distros, that had better-planned migrations (Arch, Fedora, SUSE, etc. etc. etc.) had basically no issues migrating to systemd, and have benefited immensely from being able to ditch the maintenance overhead of diverging init systems and init scripts, all re-implementing the same new features with slightly different implementations due to previous slightly differing implementation details.
People will currently call out OpenRC as the one non-systemd approach that works (e.g. if you acknowledge that SysvInit no longer actually works because no-one uses if for all system initialisation, instead leting it delegate lots of control to other bits and pieces), but before systemd won, there were: * SysVinit + RH-derived initscripts * Sysvinit + SUSE-style initscripts * Upstart * OpenRC * prcsys - parallel rc system (Mandrake and derivatives)
All of these had similarities, and small differences, e.g. they all tried to support dependency information in init script headers.
As a sysadmin, it was frustrating to: * Have to read every init script to see where it read its defaults from, was it /etc/sysconfig/pkgname or /etc/default/daemonname . Did it support setting limits from the defaults file, or would you have to hack the script to support your bigger-than-the-maintainer-imagined environment. * Debug where the application was logging to, if it didn't setup logging correctly by default.
As a maintainer of a package used on more than one distro, it was difficult to: * Test your init script to ensure it worked on RH-based distros and SUSE and Debian and Ubuntu. While Upstart said it supports init scripts, it fails in some random way that doesn't occur on RH and SUSE. * Setup logging correctly, as not all distros provided a helper script to setup the right logging daemon (syslogd, vs rsyslog vs syslog-ng etc.)
We won't talk about the more modern features such as cgroups etc., where only about 2 init systems support the feature adequately, and no distro or packager actually managed to support such advanced features on more than one init system, and certainly not more than one non-systemd system.
systemd mainly stays out of my way, but makes it easy to troubleshoot and customise daemon behaviour in a consistent fashion.
> But trying to wrap your head around systemd in even a few hours isn't reasonable.
You don't need to wrap your head around systemd to do things with it that you would really struggle to do with any other init system. But, you've probably been too busy fighting it, or trying to prove why it's worse, rather than trying to do real things with it, or you would be able to point to valid bug reports.
> The proof in the pudding for me is to look at the running processes of a default system between BSD and Linux with systemd. Yikes.
You're comparing apples and oranges here, you should rather be comparing two release of the same distro, before and after systemd became the default, and you would have seen very little difference.
This requires that you blow a publicly-advertisable prefix for every unique combination of services you would want to fail-over.
E.g., if you wanted to be able to have independent fail-over between your customer-facing self-service portal and your webmail interface (each relying on specific state that you can't replicate synchronously, and can't guarantee replicate consistently with each other), you would need to /24s, one dedicated to anycast for the webmail interface, one for the self-service portal, and separate from any services which are active-active.
Whereas using DNS, you could use your other existing public /24s that you are already using for your active-active services.
In the last days of IPv4, an extra 2 /24s just for this is quite an expense.