5 ms·

Build on Kubernetes from Day One

37 points by mariuz 5y ago

debarshri 5y ago
It is a nice starter blog. However, I disagree with few things as follows - 1. I think you should be able to run any service that you are building locally because faster the inner loop or feedback cycle is, faster you can iterate. So starting out right away on kubernetes prevents you from doing that because you can get stuck with unnecessary chores. 2. The blog makes sense in the context of a large organisation. But if you are a small startup or scale up, have simple RoR, Django, LAMP stack. It is really a lot of unnecessary accidental complexity you have to deal with before solving the real problem. You are better off with docker compose.
bamboo2 5y ago
“ When we started building Stack Overflow in 2008, we didn’t have that choice. There was no Docker (2013), no Kubernetes (2014). Cloud computing was in its infancy: Azure had just launched (2008), and Amazon Web Services was about two years old. What we built was designed for specific hardware and made a lot of assumptions about it.” Frankly, I miss those days.
amerine 5y ago
Sigh. More “Kubernetes == Containers” words to throw on the pile. It’s easy to find issues/point at problems with the post, but I’m happy the author is suggesting long-term view of your system and is making a suggestion that k8s could help, that may be true along some slices, but you are biting off learning a complexity you may not be ready for.
- throwaway894345 5y ago
  > but you are biting off learning a complexity you may not be ready for. I really think people forget how complex it is to manage VMs in any sort of reliable, reproducible fashion. In my opinion, there's a lot more complexity in configuring your process management, SSH, key management, host metrics, log exfiltration, reverse proxy, etc than there is in using a managed Kubernetes offering like EKS or GKE. You end up reinventing a lot of things with VMs to get to a state that these managed Kubernetes services give you out of the box. This doesn't diminish the complexity of using Kubernetes, but the "simpler alternative" is something like Heroku, not EC2 (to be clear, you didn't advocate for EC2, I'm rebutting the predictable, popular argument).
  - wlpu 5y ago
    I hope one day people realise there is a place other than kubernetes and VMs to run containers, such as GCP's Cloud Run or AWS's ECS Fargate, these are essentially plug container and play services which avoid the baggage of kubernetes and VMs
    - throwaway894345 5y ago
      Yeah, although I get the feeling that at least ECS/Fargate will fall behind EKS as the EKS ecosystem matures (not so sure about the GCP world).
mike1o1 5y ago
I'd argue that rather than building on Kubernetes, you should instead build a 12-factor app (https://12factor.net/ https://12factor.net/). Those principles should allow you to take your app anywhere fairly easily, from Heroku to Kubernetes.
- sergiomattei 5y ago
  Wholly agree with this.
- remram 5y ago
  I think the article supposes you have multiple components to run together.
khaledh 5y ago
And babies should walk once they're born. Why go through the phases of learning and growing when you can just "walk".
- pope_meat 5y ago
  I only hire 10x and 100x babies, they're just so much more productive, well worth the extra candy.
erulabs 5y ago
Assuming you’re relatively senior and familiar with containers and kube - learn Skaffold. Skaffold and kube are wonderful and the rough edges are being sanded down daily. I wouldn’t dream of starting a new project without it and it’s increased my velocity considerably
joelbondurant 5y ago
Never, when I'll take advice from a point-n-click infrastructure jockey.

37 points by mariuz 5y ago

It is a nice starter blog. However, I disagree with few things as follows - 1. I think you should be able to run any service that you are building locally because faster the inner loop or feedback cycle is, faster you can iterate. So starting out right away on kubernetes prevents you from doing that because you can get stuck with unnecessary chores. 2. The blog makes sense in the context of a large organisation. But if you are a small startup or scale up, have simple RoR, Django, LAMP stack. It is really a lot of unnecessary accidental complexity you have to deal with before solving the real problem. You are better off with docker compose.

bamboo2 5y ago

“ When we started building Stack Overflow in 2008, we didn’t have that choice. There was no Docker (2013), no Kubernetes (2014). Cloud computing was in its infancy: Azure had just launched (2008), and Amazon Web Services was about two years old. What we built was designed for specific hardware and made a lot of assumptions about it.” Frankly, I miss those days.

amerine 5y ago

Sigh. More “Kubernetes == Containers” words to throw on the pile. It’s easy to find issues/point at problems with the post, but I’m happy the author is suggesting long-term view of your system and is making a suggestion that k8s could help, that may be true along some slices, but you are biting off learning a complexity you may not be ready for.

throwaway894345 5y ago
> but you are biting off learning a complexity you may not be ready for. I really think people forget how complex it is to manage VMs in any sort of reliable, reproducible fashion. In my opinion, there's a lot more complexity in configuring your process management, SSH, key management, host metrics, log exfiltration, reverse proxy, etc than there is in using a managed Kubernetes offering like EKS or GKE. You end up reinventing a lot of things with VMs to get to a state that these managed Kubernetes services give you out of the box. This doesn't diminish the complexity of using Kubernetes, but the "simpler alternative" is something like Heroku, not EC2 (to be clear, you didn't advocate for EC2, I'm rebutting the predictable, popular argument).
- wlpu 5y ago
  I hope one day people realise there is a place other than kubernetes and VMs to run containers, such as GCP's Cloud Run or AWS's ECS Fargate, these are essentially plug container and play services which avoid the baggage of kubernetes and VMs
  - throwaway894345 5y ago
    Yeah, although I get the feeling that at least ECS/Fargate will fall behind EKS as the EKS ecosystem matures (not so sure about the GCP world).

mike1o1 5y ago

I'd argue that rather than building on Kubernetes, you should instead build a 12-factor app (https://12factor.net/ https://12factor.net/). Those principles should allow you to take your app anywhere fairly easily, from Heroku to Kubernetes.

sergiomattei 5y ago
Wholly agree with this.
remram 5y ago
I think the article supposes you have multiple components to run together.

khaledh 5y ago

And babies should walk once they're born. Why go through the phases of learning and growing when you can just "walk".

pope_meat 5y ago
I only hire 10x and 100x babies, they're just so much more productive, well worth the extra candy.

erulabs 5y ago

Assuming you’re relatively senior and familiar with containers and kube - learn Skaffold. Skaffold and kube are wonderful and the rough edges are being sanded down daily. I wouldn’t dream of starting a new project without it and it’s increased my velocity considerably

joelbondurant 5y ago

Never, when I'll take advice from a point-n-click infrastructure jockey.