back to article A new Habitat for applications? Chef launches open source app automation project

Chef, IT automation for DevOps, has announced Habitat, an open source project for application automation. Developing and deploying software is too hard, according to Chef co-founder and CTO Adam Jacob. An application may work fine on a developer's laptop or as a prototype on a single VM (virtual machine). "However, if you …

  1. Anonymous Coward
    Anonymous Coward

    DevOps in easy mode?

    But... but... how are you going to justify training and seminars and books and rent-an-experts and lots and lots and lots of articles for something that is easy?

    Unless it was easy because we've been doing it all the time but didn't add a fancy, hyperconverged, metaparadigmatic name to it. Nah, too crazy.

  2. Anonymous Coward
    Anonymous Coward

    Sounds useful ...

    From an application's perspective - 'Let me wrap my arms around you. I'll keep you safe and healthy". Almost motherly (or fatherly).

    And how long before Chef gets bought up by one of the big predators out there, and those loving arms start to rifle the applications' metaphoric pockets for information that can be monetized?

  3. Anonymous Coward
    FAIL

    Developing and deploying software is too hard

    What makes developing and deploying software too hard is the half-baked array of horrible tools that are foisted on real developers, starting with Maven - possibly one of the worst pieces of software ever written (and I have experience with WebSphere - so I know 'bad') - and continuing on with all the badly thought out nonsense being noisily hawked under the DevOps banner.

    All the Adam Jacob types of this world generally want to do is talk and talk and talk. In their happy-talky land of cute company names, spontaneous funding and eternal beta-ness, nothing is ever finished and nothing ever quite works. And that's fine - it's DevOps, it's cloud, it's cool, it's a double lattecino, go easy on the milk.

    The moment your deployment tools need to become more complex than a small shell script is the moment you should grab a marker pen and write 'I lost all I ever knew' on your forehead - then you should walk straight out of your office and find yourself a new career path.

  4. Anonymous Coward
    Anonymous Coward

    So looked at the documentation and this feels like rpm for docker. Sure it's cool for those in a space where they're not reliant on old school applications but I'm struggling to see its use in traditional organisations.

    I'll learn how to use it mind, one day I may work at one of those companies.

  5. Steve Aubrey
    Unhappy

    TOML

    From the linked TOML repository:

    "Latest tagged version: v0.4.0.

    Be warned, this spec is still changing a lot. Until it's marked as 1.0, you should assume that it is unstable and act accordingly."

    I like the idea of Habitat, but I want to see a solid framework, not smoke and mirrors, TOML and Rust.

  6. Anonymous Coward
    Anonymous Coward

    What about containers ?

    "A Habitat package includes the software and all its dependencies and configuration options."

    So it's the same as a container.

    What's the difference with the Habitat supervisor and a container orchestrator then ?

  7. Anonymous Coward
    Anonymous Coward

    How is Habitat different than Docker?

    I watched the videos, did the tutorial, read the docs, read the tech site stories but I still don't see why I would use Habitat over the current Docker workflow and ecosystem (including third party) for building, shipping and deploying applications. Both are a type of packaging that puts the application, its dependencies and configuration in a bundle that can run exactly the same everywhere. Docker has Dockerfiles and docker-compose.yml files, Habitat has plan files (seems like a shell script, Dockerfiles and compose files are much simpler). Docker has a central repository/registry "docker hub", habitat has depots. "docker run redis" == "hab start core/redis", etc... etc...

    The docs/articles say habitat apps can run in containers, but why bother if your app can already be run in a container that achieves the same thing with even greater isolation (cgroups). Why put a self contained app in a self contained container application?

    I'm not trying to put down Habitat, I'm trying to understand its role. As I currently see it, why would I choose this over the more mature Docker environment with a massive established ecosystem and user base?

    Again I'm just trying to understand what I'm missing, if I'm missing something please point me in the right direction.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like