Azure Container Instances

For small teams like the one I work in, and for solo work I have dabbled a bit in, I can imagine the following thought process if I have a git repo and sit down to think about how to best deploy it.

- I start researching how to deploy this, but I don't care about optimizing for a lot of scale. I DO care a lot about iteration speed, integration with image registry + code repository + CI/testing services (ideally out of the box), and not making it hard to maintain/deploy/expand for the rest of the team (if an associate engineer can be brought up to speed on the infra and become fairly independent, that'd be wonderful).

- I probably care about burstable, pay-for-usage infra. But it'd be great if that was somewhat abstracted away. Perhaps even based on requests-per-minute, and I set up limits about how far it should scale. (This would immediately put this far and above Heroku -- good, cost-efficient auto scaling)

- I really care about not having to maintain my own DB cluster myself. And similarly for key/value storage and block-file-storage (like s3). And I'd absolutely love to not have to myself tweak and implement something common like cron or logging.

- And I'd probably care about integration with error-detection services and performance monitoring services.

- It would be absolutely amazing if there were default stacks/recipes with load balancers, so the common cases were easy (a common case like a standard RDBMS-backed JSON REST Api using cron and background jobs, or a static website (which basically covers all SPA-like frontends, if you add in a flexible reverse-proxy URL-rewriting solution))

Then, I could pick it up and be fine depending on it, since costs would scale down to my level (plus some premium I guess, but hey I'm even okay with Heroku for some things). But I could probably continue to stick with it for a long time. Inertia in ops means that if you get green field projects early and sustain them, my guess is that they stick around longer than they really even should -- but that's just an unverified guess on my part, idk.

ps -- the thing that really strongly drew me to hyper.sh was that I could abstract away the whole cluster behind `hyper`, like `docker` on my own computer. That was an amazing selling point, coming at after the popcorn machine of container management solutions with their very own intricate towers of complexity. It's what I like about sandstorm.io in part -- abstracting away a lot of complexity about hosting apps. But there's other complexity that could perhaps be eased or simplified, since running a software project is not simply the same as running an app on a computer, networking, load balancing, data security, backups and so on add up to a lot. So it's not enough that `hyper` abstracts away the data center, because there's scope for some more simplification for a certain slice of market: smaller teams who can't afford a full ops team, or teams with a small ops team who want to tackle a monstrous tech project.

Check out Hyper.sh too. It abstracts away the whole datacenter -- you can use `hyper` instead of `docker`, basically. You don't need to think about VMs ever as a concept, containers run directly on the hypervisor. And they have Hyper Func, an AWS Lambda-like alternative that uses images. And per second billing.

On the downsides, they're small and they have one data center, and they're not Microsoft. But their tech is open source.

Thank you, I will.

Good point about the "getting it" with their docs. I suppose there's always that ethereal point with new concepts... It's just frustrating when it takes so long to get there. And, somehow, once you're there, it becomes incredibly hard to empathize with people who don't "get it" yet. Consequently, docs suffer.

As the old joke goes: Once you understand monads, you immediately lose the ability to explain them to others.

Anyway, good to hear they've improved and stabilized.

We don't want to compete with the big providers, instead we open source the tech to enable more container-native clouds, where the world will become a seamless (portable) network for containers (different clouds are different ports with the same image spec and API).

I would like it if the major cloud providers implemented microsecond boot and teardown times for instances along with suitable pricing.

Unikernels and a whole zoo of other types of tiny operating systems would be enabled by this.

I'm not a fan of containers - I feel they are reimplementing much of the operating system infrastructure within the OS at the price of high and unnecessary complexity.

It's frustrating that cloud computing has so many benefits, but at another level we must wait and hope that Amazon Google and Microsoft are willing to implement new architectures such as microsecond level boot and teardown.