101–110 of 268 posts
In my company, we were aware about the potential honeypots in each cloud and we developed our product from the first commit to be deployed on 3 (!) clouds: AWS, Azure, IBM. And while we made it work by sticking to the least common denominator which was FaaS/IaaS (Lambda, S3, API GW, K8s). It was certainly not easy. We also ignored tools that could've helped us greatly only against a single cloud in order to be multi…
Earlier quoted context omitted.
> None of us are or want to be sysadmins. It's such a huge misconception that by using a cloud provider you can avoid having "sysadmins" or don't need that kind of skills. You still need those, no matter which cloud and which service you use.
Which skills specifically do you think we might be missing that we would need to run an app on a managed container service and managed database? I know how to configure firewalls, set up a (managed) load balancer, manage DNS, and similar tasks directly related to getting traffic to my app. What I no longer have to know how to do: keep track of drive space, manage database backups, install security updates on a produc…
Those things you listed are sill sysadmin tasks in my eyes, and you are doing them, validating my point.
You still have to track storage space, either because you are paying for it and need to expand when necessary, or you have to manage costs at one point, that's not completely out of the picture. It can be easier for sure than building your own storage hardware.
You still need to keep systems up-to-date either you are using Docker so you are doing it on your "application level" or you are using Linux VMs and you need to upgrade those systems/images. Even if you are using something like Functions or Lambda, those have their own environment which you need to be aware of and they usually support specific versions of programming languages, so you need to upgrade your own stack when they don't support older versions anymore.
In my company, we were aware about the potential honeypots in each cloud and we developed our product from the first commit to be deployed on 3 (!) clouds: AWS, Azure, IBM. And while we made it work by sticking to the least common denominator which was FaaS/IaaS (Lambda, S3, API GW, K8s). It was certainly not easy. We also ignored tools that could've helped us greatly only against a single cloud in order to be multi…
Also, in both cases, it was moving from AWS to GCP, and in both cases we were using Kubernetes and not really using much of the provided services of the platforms. I suspect this is the biggest reason for Google to push Kubernetes; abstract away compute so it's easier to switch.
Moved a SaaS tool from Linode to DigitalOcean. Reason for the move was security driven. DO's K8S volumes are LUKS encrypted at rest by default; one less thing in your security controls to worry about. Prices are higher than Linode's, and have had some reliability issues occasionally with the LoadBalancer, but for the most part it works really well. The SaaS tool was mostly cloud-agnostic, so the changeover was not te…
He spent a lot of time debugging it with a minimal example to rule out other causes, iirc a websocket pinging every few seconds on their kubernetes offering (again, I'd have to ask for the details), and it reproduced on Linode but not on the platform they were considering moving to (with a similar hosted kubernetes offering).
Yes. Huge AWS -> GCP migration. Why? Incoming CTO signed a massive GCP deal probably because it was marginally cheaper than AWS (while probably ignoring the migration costs).
Same thing happened to my old company (large insurance company). Moved from Azure to AWS + Terraform/Kubernetes because of cost and "cloud independent" nature of Terraform. The whole IT department spent 2+ years moving hundreds of (relatively modern + legacy) services and applications. Some services couldn't move because they were managed by third-party. I am pretty sure they didn't factor in the cost of migration.
Went from AWS to GCP. Everything we deploy is on Kubernetes, so a combination of Terraform and ArgoCD was pretty easy to move. It was pretty much push button.
In my company, we were aware about the potential honeypots in each cloud and we developed our product from the first commit to be deployed on 3 (!) clouds: AWS, Azure, IBM. And while we made it work by sticking to the least common denominator which was FaaS/IaaS (Lambda, S3, API GW, K8s). It was certainly not easy. We also ignored tools that could've helped us greatly only against a single cloud in order to be multi…
Also cold start times for serverless differ greatly between those cloud providers. AWS is < 1 second, whereas Google Cloud is 5-10 seconds
Amazon EC2 to OVH AI Docker. Price for GPU instances went down 80%.
Can't find an OVH product by that name (would have surprised me), is this a buzzword bingo joke?