> Digital Blog
> A blog by the Guardian's internal Digital team. We build the Guardian website, mobile apps, Editorial tools, revenue products, support our infrastructure and manage all things tech around the Guardian
> Due to editorial requirements, we needed to run the database cluster and OpsManager on our own infrastructure in AWS rather than using Mongo’s managed database offering.
Disclaimer: The voice is my head does not come out of nowhere. I am building a product which addresses this: https://github.com/wallix/datapeps-sdk-js is a API/SDK solution for E2EE. Sample app integration is available at: https://github.com/wallix/notes (you can switch between master and datapeps branches to see the changes of the E2EE integration)
Our software E2EE solution has advantages over HSM though: Cost obviously, and more features and extensibility.
How is running on AWS different than Guardian Cloud in their basement?
Did reports of the Snowden revelations reside on the CMS?
After all, the client computer that connects to the CMS is just as, or more likely to be compromised. I wouldn't be surprised if the coverage (or at least parts of it) were edited on airgapped laptops.
If those were the only two choices, you might be right. But the resources needed for the actual CMS functionality sound modest enough to run independently of the main website.
> the client computer that connects to the CMS is just as, or more likely to be compromised
That's faulty reasoning.
Why? It's an obvious potential point of compromise.
Can I ask what was the total cost of the migration?
If there was software that could do this database migration without downtime, how much would you/Guardian be willing to pay?
Guess it makes sense to reuse the platform that already has the templates than use another platform and reimplement the design.
Well done and congratulations to everyone on the team.
In most early stage startups, that would be an unacceptable loss of time.
So I don't judge them for doing a one-shot migration even if it causes an hour of downtime.
It all depends on the business.
Another team at the guardian did a similar migration but went for a 'bit by bit' approach - so migrating a few bits of the API at a time - which worked out faster, in part because stuff was tested in production more quickly, rather than our approach with the proxy which, whilst imitating production traffic, didn't actually serve Postgres data to the users until 'the big switch' - so not really a continuous delivery migration!
Part of my duties at work require me to deal with "large" issues. While a solution to them is usually necessary and quick and high quality, I've seen the analyses that come after them vary in quality.
Good writeups tend to stick around in people's memories and become company culture, and drive everyone to do better. Bad writeups are forgotten, and thus the lessons learned from them are forgotten as well.
This particular article stands out for me. English is not my first language, and I've spent most of my life dealing with very fundamental technical details, so most of my writeups aren't the best. I'm going to bookmark this one and come back to it to learn how to write accessible technical narratives.
I don't even.
I like the article but it was a bit hard for me to consume with multiple voices in different parts.
We accured lots of downtime due to mongo.
But later versions were rock solid and I've matainer mongo installations at many startup and SMEs once you setup alertd for disk/memory usage, off you go. Works like charm 99% of the times.
Not that that's really a surprise or was unknown, it's just fairly new to see in the open source ecosystem instead of the enterprise one.
SQL has decades of production maturation, and has wider domain knowledge.
Great read. Well done.