Curious what service management are you using for all of these docker run commands, systemd? I see you mention that you might consider Prometheus at some point, is there any process monitoring if one of your services crash?
Oh man, don't get me started. The 3 _calendar_ month notice that needs to be sent in writing (or faxed) is so ridiculous and I wonder if it is done to make it more difficult to get out of contracts. In my case, I had no idea that the written notice receive date matters (unlike the US, where you typically use the postmark date), due to mail delay because of a holiday my notice arrived 2 days late and that was enough to make them pay for another month despite there being an incredible amount of demand in Berlin for apartments.
> I should also point out something else unfair. I am a dual US|EU (Croatian) citizen who works part-time remotely as a contractor for a US-based company in Croatia, while studying for her masters degree in electrical engineering full time. Because I am an EU citizen, I can work in 30+ countries remotely, outside of the United States, while essentially getting paid more (compared to the locals and most other European Union citizens) for just having US citizenship and related credentials.
For another perspective as a US citizen living in Europe, getting work remotely for US company really only works in tech from what I have seen (maybe in other professions, but they are not that common). What you need is the combination of being able to work on contract, and hopefully not have to shift your hours unless you are working part time. For companies that are large, established, and have remote workers you will likely be paid at market rate for where you live. The tax situation can get complicated depending on your income level, and tax rates in most European countries are much higher than the US. Your investment options outside the US are limited, many expats retain their US banks for this reason. You won't have the benefit of a 401k contribution either. The best situation for employment is being able to invoice a company directly and get paid on a contract, not every company is willing to do this. Otherwise, worst case you would be employed by a local PEO which means for tax purposes you are a full time employee and will likely be paying more taxes than you would in the US. I think Croatia might be in the sweet-spot of countries that hasn't a decent quality of life but also low taxes for independent contractors.
This is pretty cool, looks similar to something I built awhile back (https://cmdchallenge.com), would love to know more details on how you built the backend, how you are sandboxing commands, if you are doing any caching, etc.
They are the main food delivery in Slovenia and have pretty much completely taken over incumbent due to the better service and better quality application.
thanks for the info, I've been hearing a lot of horror stories about kids lacking computers since the lockdown. I'm also in Slovenia (LJ), living here as an expat.
small plug - around 6 years ago I created a javascript game that uses Figlet fonts to make arbitrary Atari Breakout-ish boards. Here is a demo - https://jarv.gitlab.io/figlet-breakout/
> Actual analysis by the engineers of one of their migrated jobs (urgent-other sidekiq shard) says their cost went from $290/month when running in VMs to $700/month when running in Kubernetes. They tried to use auto-scaling but failed completely and ended up disabling it:
Note this is just one service out of many and has very low latency requirements, and due to our slow pod start times in this case it didn't make sense to auto-scale. We are auto-scaling for other services in K8s.
> says their cost went from $290/month when running in VMs to $700/month
These numbers represent a snapshot in time where we are overprovisioning, for this service for the migration. You are correct that cost benefit here remains to be seen for this service. We are doing things like isolating services into separate node pools which may not allow us to be as efficient.
Safer and faster deploys was a huge win for us, for this service and others. This of course is compared to our existing configuration using VMs and Chef to manage them.
Yeah, this is why we decided to migrate it first about a year ago, and we probably could have done it sooner than that. Other services were not yet ready to migrate until recently due to some blocking issues which was a factor in the decision.
It has been possible to run GitLab the application on K8s for some time now for the majority of self-managed deployments. There were some limitations however, for running GitLab on K8s at the very large scale of GitLab.com that we have been working through in the last year.
Blog author here - we are using Helm for our application because of how much we have already invested in our public Helm chart.
We are not sold on using Helm however for K8s in general and are currently evaluating Tanka for some of our monitoring infrastructure. One of our engineers wrote up some notes on that here if you are curious https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issu...