3 ms·
I do think they need to put more effort on CLIs etc, instead of relying on OSS to fulfill this niche, or at very least put more effort into supporting OSS. Lam
by tjholowaychuk 10y ago
I do think they need to put more effort on CLIs etc, instead of relying on OSS to fulfill this niche, or at very least put more effort into supporting OSS.
Lambda is similar, we have 'Serverless' and I'm hacking on Apex (https://github.com/apex/apex https://github.com/apex/apex) just to make it usable. I get that they want to create building blocks, but at the end of the day consumers just want something that works, you can still have building blocks AND provide real workable solutions.
I was part of the team migrating Segment's infra to ECS, and for us at least it went pretty well, some issues with agents disconnecting etc I sort of wrote off since ECS was so new at the time.
Another annoying thing not mentioned in the article is that the default AMI used for ECS is not at all production ready, you really have to bake your own images if you want something usable. I suppose this is maybe because there's subjectively no "good" defaults, I'm not sure, but it's a bit of a pain.
ELB for service discovery is fine if you can afford it, I had no issues with that, ELB + DNS keeps things very simple. I'm not a huge fan of all these complex discovery mechanisms, in most cases I think they're completely unnecessary unless you're just looking to complicate your infrastructure.
I also think in many cases not propagating global config (env) changes, is a good thing, depending on your taste. Scoping to the container gives you nice isolation and and more flexibility if you need to redirect a few to a new database for example. You don't have to ask your-self "shit, which containers use this?", it's much like using flags in the CLI, if we _all_ used environment variables in place of every flag it would be a complete mess.
EDIT: I forgot to mention that the ELB zero-downtime stuff was awesome, if you try and re-invent that with haproxy etc, then... that's unfortunate haha. No one should have to implement such a critical thing.
- maslam 10y ago>Another annoying thing not mentioned in the article is that the default AMI used for ECS is not at all production ready, you really have to bake your own images if you want something usable. I suppose this is maybe because there's subjectively no "good" defaults, I'm not sure, but it's a bit of a pain. We ran into this as well - I forgot to add this to the post. The Amazon Linux AMI for ECS has _very specific defaults_ that need tweaking.
- nathanboktae 10y ago> I also think in many cases not propagating global config (env) changes. ... You don't have to ask your-self "shit, which containers use this?", I agree and we (dev lead at Appuri here) achieve the best of both worlds from Kube by in the secrets section of a deployment definition, specifying what secrets we need, but not the value. So we know what services need it, and it's updated in one place. That's just for the secret store though, but we could put non-secrets in secret to use that mechanism.
- cpitman 10y agoHave you looked at ConfigMaps? They're a newer feature of Kubernetes that is meant for storing non-secrets, but in general works pretty similarly to how secrets work (create config map, mount in container).
- nathanboktae 10y agoOh I'll have to check it out, thanks!
- velkyk 10y agoSure, we use configMaps, secrets, mounting EBS, you name it. Implementing k8s felt like Jack in Titanic getting into first class :). Nice to know they won't lock you up when the boat is going to sink :). configMaps is nice, but we use it in limited way because its so much easier to update pods when editing env vars. Note: we are using deployments, so if you need to change env var, you do `kubectl edit deployment <name>`, edit/save/close file that opened in your $EDITOR and watch the magic to happen.
- shinzui 10y agoCould you elaborate on the problem with the default AMI?
- tjholowaychuk 10y agoTypical stuff like fd limits and network configuration etc. With a light load it would be fine, It's just a shame that you can't boot up an ECS and know it'll scale with you out of the box. That said this does fit the rest of their services involving EC2, so I guess it's not much different there, but as a consumer I just want the thing to work.
- velocitypsycho 10y agoCould you elaborate more on the issues with the default AMI?
- rdtsc 10y ago> instead of relying on OSS to fulfill this niche, or at very least put more effort into supporting OSS. From whath I hear from people working there, OSS is king but there is also little contribution back to OSS so fits with what you mentioned. (But I only know about a few AWS services, maybe it is different for others).
- scrollaway 10y agoApex looks great, can you talk a little more about it? Lambda doesn't currently support Python 3 (only Python 2.7) and that has been a massive pain in the arse to deal with. I've heard it's possible to get Python 3 working on it by shipping a custom executable and serializing/deserializing state but I figure it's a fairly significant performance hit.
- xrjn 10y agoHow would one ship this custom executable with python 3? I have played around with aws lambda and zappa, this was a major frustration for me.