foxylion

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.

You can also just do a normal form post request into an invisible iframe that is generated by the attacker's javascript.

This is, as far as I know, only possible if you bought it online.

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.

Yes, it has a package registry feature for NPM and Maven:

Maven: https://docs.gitlab.com/ee/user/project/packages/maven_repos...

NPM: https://docs.gitlab.com/ee/user/project/packages/npm_registr...

Did you try to upgrade using AWS database migration service?

Normally the operational status is automatically updated on outages. The past incidents part is managed manually.

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.

I wonder who is writing those status messages. as a customer this reads like "please wait, ETA to fix unknown" in 10 different ways.

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.

Yes, we are planning to just fail, as the chance of a collision is really low and the user will then be able to just retry creating the object.

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).

I think hosting the repository is one thing.

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).

Yes, as mentioned in my other post, ChargeBee does this really well. We, as a German company, use it for our SaaS offering.

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.

They have also an extensive API and webhooks.

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.

Yes... But such blog posts are terrible. They share bad knowledge and so many people trust such blog posts and make decisions based on this.

I don't get it. When you limit the memory of the java process it will be a _lot_ lower. A spring boot server can be started with -Xmx64m. Setting the memory limit to 200mb is more than enough to prevent OOM kills in Kubernetes.

We run many spring boot services in that way. With absolutely no issues.

Edit: just checked it, -Xmx32m is also usable.

My hope is that at some point the auto sync is smart enough so we don't need any refresh button.

For example: Instagram does auto sync of new posts, but it also has a refresh functionality. So I never know if it is up to date and I must refresh. When you know about a manual refresh functionality the auto update is totally useles. You're never sure if the app tries to stay up to date or does only occasionally sync to show some (not the latest) updates.

Another example is google mail, it does auto sync pretty well and I always see the mails when they arrive. But the refresh buttons makes me suspicious if it's really up to date (in my experience it always is).

You would expose a counter with the total request count. Summing those up across all nodes known by Prometheus will give you the total amount of requests currently visible to monitoring. With "rate()" you could calculate the requests/second.

But yes it is possible to miss some requests if a node goes down without Prometheus collecting the latest stats.

But as the parent said, if you need such totals it might be better to store them persistently. Also I do not know a scenario where the total number of requests will trigger an alert.

In this case (ingress controller) this is done with a Prometheus metric exporter. So all the metrics are available in Prometheus.

https://github.com/hnlq715/nginx-vts-exporter

If they do it there would be someine at some point who would leak information about this. And this will probably much worse than loosing some customers.

Nonetheless with Amazon Marketplace they already habe a platform where they know every transaction, price and product from third parties.

We also did some evaluation and then decided to stick to KISS an chose kubectl commands combined with cat and kexpand. Really simple approach to allow dynamic kubernetes deployments.

Example command can be

   cat service.yml | kexpand expand -v image-tag=git-135afed4 | kubectl apply -f -

An engineer only has to create the service.yml and Jenkins does deploy it automatically on every master build.

*kexpand is a small tool which does something similar to sed, but in a simpler and less powerful way (keep it simple): https://github.com/kopeio/kexpand

Traffic pricing for CloudFront is similar to standard traffic pricing on AWS (e.g. for EC2 instances). They charge you also per request and user origin a bit extra, so in some cases maybe even more expensive.

As a German it is hard to believe that such things do not exist yet in other countries. We have a standardized protocol called FinTS which is implemented by most banks. This results in a huge amount of desktop and mobile applications for banking.

They did not lose that much data, only a few hours.

In the aspect of scrum the daily is good defined, I don't think you need to experiment about what needs to be talked about.

It is a one time a day meeting where everyone gives a glimpse over what he has done and how this may affect others and what he is going to achieve until the next meeting. Committing to a goal motivates me to get things done. A third aspect is to give the scrum master feedback about impediments which do prevent me from achieving my goals.

And yes this does not mean that nobody is talking to each other through the day. But even if you are a team it is important to get everyone up to date. Most discussion through the day happen between 2 or 3 persons, and not with everyone (4-6 people).