When I write a bot like this I generally prefer using browser automation (like puppeteer). This requires less reverse engineering and is often a lot simpler and faster to implement.
You can now link the takeout to another cloud provider (e.g. Dropbox or Microsoft OneDrive). And configure the takeout to take place every two month (for up to 6 times).
So you just need to configure the takeout once a year and you'll automatically receive a backup once every two month.
But managing an IRC server cluster for 10.000+ users is no simple task.
Paying experts in their field (chat tools in this case) is most of the time the most reliable and cheapest variant. You must also include that Slack has plenty of features that are not available in IRC and mean the productivity is not as good.
Nearly everything.
Old k8s version. No upgrade possible. Odd deployment process (not fully automated). Support is unable to help in a timely manner. First deployed cluster was directly broken (no DNS resolution).
We eyed on switching from kops to EKS. But immediately stepped down after experiencing so many issues.
Yes it is nice for experiments, but if you already invest thousands of dollars a month for cloud resources, an additional 150$ are for sure not a problem.
I second this. This means you don't have to setup and manage those master nodes. AWS will do this for you. A developer fixing an issue with your self-managed master nodes will be much more expensive than 150$/month.
As an individual this may look expensive, but as a company this is much cheaper than paying the loan of a developer.
The article contains a footnote about UUIDs as primary keys.
> UUID as a primary key is a terrible idea, by the way — cryptographic randomness is utterly designed to kill locality of reference, hence the performance penalty
Is there anyone who can go a little bit more in detail?
We planned to migrate our database to use UUIDs as primary keys. This will allow creating new rows on clients knowing the new primary key before sending them to the server (simplifying client and server code).
But integrating those two repositories with all the automated workflows is quite a headache. Jenkins won't automatically switch over to another git backend if one fails. Other automated tools like code review are mostly relying on a centralized repostiory. I don't see any simple solution to solve these issues. Bitbucket, GitHub, GitLab don't have any easy fallback solutions when you relying core workflows on their services.
Self hosting is maybe one solution (we do this with bitbucket), but this requires major administrative effort to keep it running reliably (always available, no data losses on hardware/software failures).
We use ChargeBee for our SaaS product.
Really great offering!
They give you a customer portal where the customer can cancel, update, upgrade, ... his subscription. We have a custom checkout page where all options are listed. Then one API call and the user is forwarded and can fill out billing address, payment information, etc. on a ChargeBee page. They will handle taxes, issue invoice and everything else for you.
It depends on the user base. Customers of the company I work for mostly use IE or Edge and only Chrome because we highly suggest it. Without decent IE/Edge support we would have less customers.
What you forget is: You get so many features with Spring Boot and you can actually use them without increasing the memory footprint.
Yes of course, for a single service with one endpoint that does nothing it is bloat. But which microservice does nothing?
Think about a database backend, actuator endpoints, etc. They are all possible with a memory footprint of ~200mb. It can be less is you use another language, but I doubt that Go will give you such a major framework for developing a microservice. And this will save you a lot more time than taking an hour to reduce your memory footprint.
And one thing you missed too: Using the JVM should also be combined with a basic knowledge about how the heap works. And if you do not limit it, it will get a lot bigger than required, this should be common knowledge.
Comparing this to Go it seems like a much better way. In Go there is afaik no way to limit the heap. In worst case it will grow and grow and grow.