21–30 of 84 posts
I think that for the average developer, these tools will soon be obsolete. For frontend applications, hosting services such as Vercel and Netlify gives a far superior DX. For backend, Vercel does the same, or other BaaS' like Supabase that gives you most you would need to create a fully fledged app with easy to use API's. The only downside I can tell, is the pricing, but compared to dev hours saved, it's probably a n…
Earlier quoted context omitted.
The downside is vendor lock in. What will you do when vendor will ban your website?
not sure if IaC will help, I'm just started reading about it. Indeed the cloud vendors are all lock-ins, something needs to be designed to mitigate the switching cost among cloud providers. Each one has its own SDK and own complicated infrastructures, so far it seems impossible to switch once you started with any one of them.
Do you think cloud vendors (FAANG companies) are fools who have accidentally created this situation? And do you think they will stand idly by while you try to abstract away the differences between them?
I think that for the average developer, these tools will soon be obsolete. For frontend applications, hosting services such as Vercel and Netlify gives a far superior DX. For backend, Vercel does the same, or other BaaS' like Supabase that gives you most you would need to create a fully fledged app with easy to use API's. The only downside I can tell, is the pricing, but compared to dev hours saved, it's probably a n…
A lot of medium/large shops build their own deployment and BaaS platforms on top of Kubernetes/Terraform/AWS. You just don’t hear about them as much because they often aren’t provided as a service externally, and aren’t open sourced. (I work with and on such platforms)
The mistake I see people often make is assuming it’s worth using such complex tools directly with a small project. People like the flexibility but don’t understand cost to build/maintain it.
Why use k8s and AWS instead of ECS?
Also I don't think you can use Kubernetes logic with ECS
Finally I think with ECS you have quite the vendor lock in.
Earlier quoted context omitted.
To be fair. Just last night i was googling kubernetes and k3s tutorials. All of them on page 1 of SERPS are super simple and brilliant and ONLY show you how to add nodes to clusters. Ok now what ?? Ive drank the k-Koolaid signup for the newsletters but how do i get value from this 'thing' ??? When i code a webapp how do setup/config the db ? How do I do a regular LAMP app ? Lol i never thought i say this but i need a…
All you need exists on kubernetes.io. Start with https://kubernetes.io/docs/tutorials/hello-minikube/ and proceed. Read reference documentation on the same site whenever you need to dig somewhere. It's awesome. You don't need any other websites. I was able to build a kubernetes cluster and right now deploying multi-service application and I have had enough technical information on this website alone. As to answer you…
Most examples failed when then trying to use them together.
Also, jumping into directly K8 can be quite a jump.
I put this together to help SA Php group.
Starts off with just deploying directly on a server.
Then takes you to a full application deployed on K8 with auto SSL and DNS generation.
It needs a bit of a refresh :(
But finally coming out of being a bit over-committed, so should be updating in the next week or two.
Still some bits missing but it should cover all your basics
After a few weeks like that I deleted everything from AWS. I have an account on GCP as I had to learn few things for my work assignment and I forgot to delete the setup - anyway a few months later I got an email that Google can't bill my account. I almost got a heart attack and then I noticed they couldn't bill $0 and my card simply expired - imagine the relief.
When I wrote this I can see that maybe sounds stupid, but I have genuine fear of running anything on AWS, GCP or Azure etc.
Another fear I have is that if I put a website online, someone could run a script to fetch content forever and make me pay huge bandwidth costs. When I last checked, there is no way to put any sort of caps e.g. when bandwidth cost exceeds certain amount it would deactivate the buckets etc. So what would you do? Nowadays very much every job lists knowledge of AWS as a requirement, but I can't get myself past the fear.
Or better phrased: "How to get inclined to slash your own wrists". Jokes aside, I'll give it a go, I do need some advanced Docker topics lately and I am sure Kubernetes can help me with some of my home-hosted services as well.
I use docker only.
I get to play with kubernetes enough at work.
Or better phrased: "How to get inclined to slash your own wrists". Jokes aside, I'll give it a go, I do need some advanced Docker topics lately and I am sure Kubernetes can help me with some of my home-hosted services as well.
As a Devops engineer I'm staying away from Kubernetes at home. It would require too much constant maintenance. I use docker only. I get to play with kubernetes enough at work.
I've worked in orgs where k8s worked great but most of the time it just made everyone curse their lives.
I think that for the average developer, these tools will soon be obsolete. For frontend applications, hosting services such as Vercel and Netlify gives a far superior DX. For backend, Vercel does the same, or other BaaS' like Supabase that gives you most you would need to create a fully fledged app with easy to use API's. The only downside I can tell, is the pricing, but compared to dev hours saved, it's probably a n…
And I'd argue that with managed kubernetes solution, such as GKE Autopilot, you get roughly the same "DX", and much more flexibility to use whatever tools you fancy. GKE Autopilot manages the cluster and node availability, ingress and certificates, all you need to do is write the kubernetes yaml. As long as what you are working on fits in a docker container, you're good to go. And you're fairly good to move off of their setup, because those same yaml configs will work on AWS or self-hosted solutions, albeit with additions that fill in gaps where Google managed services lived.
Kubernetes must probably be one of the most tutorialized pieces of SW out there. You want a "crash course" on the platform of your choice? You got it. You want it for the price of your choice? You got it. The docs are great [1] and offer even interactive parts [2]. There are a ton of good materials on youtube. There are Coursera and EdX courses, e.g. [3] from Google and [4] from Red Hat. There are a ton of Udemy cour…
To be fair. Just last night i was googling kubernetes and k3s tutorials. All of them on page 1 of SERPS are super simple and brilliant and ONLY show you how to add nodes to clusters. Ok now what ?? Ive drank the k-Koolaid signup for the newsletters but how do i get value from this 'thing' ??? When i code a webapp how do setup/config the db ? How do I do a regular LAMP app ? Lol i never thought i say this but i need a…
SRE for 15 years with FAANG (MAGMA?) scale experience; I would argue this, yes. That's a little over 2 requests per minute. If you're cloud hosting then you could get away with single tiny hosts for your front end and DB, like t3.small on AWS, and Cloudwatch alarms for monitoring. If you need extreme HA or burstability even with this low rate, a managed load balancer (e.g. AWS ALB) with a few target webservers will do the trick and let you swap them out as needed without taking down the site. A DB read replica will give you redundancy there as well. This is all 20-year-old tried and true tech. You'll set it up once and it will run for years without trouble.
Once you introduce Kubernetes you've got a whole 'nother beast to feed, especially if it's self-managed, and you'll pay dearly if it's not (like EKS). For your scale, it would be kind of like buying a full sized semi truck to haul stuff for a corner store. You'd be better served with a small pickup or minivan.
Of course you don't need an "at scale" excuse to learn new tech. In which case I agree there's a dearth of practical tutorials that aren't just "here's a Helm chart." Part of this is because managing a stateful service like MySQL on K8s is not straightforward; there's a lot of ways to do it, most of them are wrong, new ways get introduced every few years, and even people who claim they've solved the issue are probably sitting on a time bomb of their own making and have just gotten lucky.