5 ms·

I do my level best to stay away from containers. I don't think most people even need them. It's a fad of sorts. I tend to stick with the tried and true and not

I do my level best to stay away from containers. I don't think most people even need them. It's a fad of sorts. I tend to stick with the tried and true and not follow trends, cloud or otherwise. Nothing worse than having your data on someone else's HW and losing connectivity through no fault of your own. Years ago, I worked for UUNET in Reston/Ashburn, VA, and built web servers and the attendant HW/SW that ran them (usually Sun Solaris/Apache/Oracle). We always had a "back net" into every device. Now? One NIC, one way in. I always like having more than one way to get to a device, be it local or remote. With the cloud, you tend to give this up. I recommend VMs over the cloud using someone else's data and data centre. Nothing worse than going to a tech conference with your boss, and him being the "deer in the headlights" as it were with regard to buying into what's being sold by the vendors. Last time we went, it took me the entire 3-hour car ride home to convince him we didn't need half of what was on offer. I tend to be old school and prefer to make do with Linux/FreeBSD VMs, and whatever software is needed to make something work. I like being in control of my own architecture.

eropple 8y ago
Containers and container orchestration are wildly different, though. A container is a pretty handy way to distribute an app to a production environment. Container orchestration is a bad application of the bin packing problem. Pretty different things.
kayoone 8y ago
problem with that mindset is that it will be harder to get hired. At least where i work, knowledge about containers and cloud services is pretty crucial to get a senior position in a bigger company.
devhead 8y ago
i like being able to sleep at night knowing my infrastructure will self heal in almost all cases.
- bashmonkey 8y ago
  HA is self-healing. And for things that don't do HA very well, there are hot spares that can be activated in 30 seconds. Depends on the SLA, though, as with most things. Most things in my firm can be stood up within two minutes' time should there be an issue with something.
Symbiote 8y ago
But containers and cloud don't necessarily go together. It took me barely five minutes to convince my boss we shouldn't move everything to the cloud — a quick estimate on the AWS calculator was enough. But he's still keen to try Kubernetes. I think we can improve our deployment process (currently custom scripts) and introduce genuine load balancing, but there's a big increase in complexity. The custom scripts aren't very long, I suspect we'll need at least the same amount of configuration for Kubernetes, plus we add Kubernetes itself. He's hoping for more ops understanding/interest from developers, and which is probably reasonable, but at the cost of less understanding of the whole system from the ops staff. I think there's some CV-driven-development too. Step 1 will have to be us documenting what we expect to achieve from Kubernetes, and how we will measure achievement.

eropple 8y ago

Containers and container orchestration are wildly different, though. A container is a pretty handy way to distribute an app to a production environment. Container orchestration is a bad application of the bin packing problem. Pretty different things.

kayoone 8y ago

problem with that mindset is that it will be harder to get hired. At least where i work, knowledge about containers and cloud services is pretty crucial to get a senior position in a bigger company.

devhead 8y ago

i like being able to sleep at night knowing my infrastructure will self heal in almost all cases.

bashmonkey 8y ago
HA is self-healing. And for things that don't do HA very well, there are hot spares that can be activated in 30 seconds. Depends on the SLA, though, as with most things. Most things in my firm can be stood up within two minutes' time should there be an issue with something.

Symbiote 8y ago

But containers and cloud don't necessarily go together. It took me barely five minutes to convince my boss we shouldn't move everything to the cloud — a quick estimate on the AWS calculator was enough. But he's still keen to try Kubernetes. I think we can improve our deployment process (currently custom scripts) and introduce genuine load balancing, but there's a big increase in complexity. The custom scripts aren't very long, I suspect we'll need at least the same amount of configuration for Kubernetes, plus we add Kubernetes itself. He's hoping for more ops understanding/interest from developers, and which is probably reasonable, but at the cost of less understanding of the whole system from the ops staff. I think there's some CV-driven-development too. Step 1 will have to be us documenting what we expect to achieve from Kubernetes, and how we will measure achievement.