char_pointer

This is really fun!

Can't stress enough how great Compute is compared to EC2. A lot of the (enterprise) companies I work with are weary of going all-in on a particular cloud and prefer to hand-roll open source solutions instead of consuming cloudy services; the most they'll use is VMs, basic networking and storage (although GKE seems quite popular as well nowadays). GCP nails this use case IMO. It's fast to provision, reliable, rarely if ever fails during setup, and you don't need a separate start-up company to predict your costs. It's very much quality over quantity though, so whilst this is great and manages to capture a particular market I do think they need put out way more (perhaps lesser quality) stuff to stay competitive with AWS and to a lesser extent Azure.

There was quite a good thread about self learning electronics recently: https://news.ycombinator.com/item?id=16775744

Just to add: I've worked on pipelines like this for dozens of clients and I'd be happy to talk more in-depth about your options, as business requirements do tend to influence your delivery pipeline a lot. Email is in my profile if you're interested.

https://github.com/ankyra/escape (disclaimer: I'm one of the authors)

We use Escape to version and deploy our microservices across environments and even relate it to the underlying infrastructure code so we can deploy our whole platform as a single unit if needs be.

Yeah, I think this is what people mean when they talk about simple Makefiles: running scripts + topological ordering. Building C is just hard.

Timestamps: it wouldn't be hard so much as expensive, because the program would have to go off to the kubernetes master for each resource to figure out the timestamp. This adds up when you're doing a `find` or even an `ls` on a pod. Could add it as an option though.

Yes, writing values is very much possible, and the replica change is not a bad idea actually. Might give that a go, thanks!

Been meaning to write something up; will keep you posted!

Thanks, mogronalol. I agree that visualisations would be useful and I think using tests to create a virtualised service definitely has merit, because it kills two birds with one stone. I like the fact that I can give my consumers/clients something that they can use to test with without having to set up or give away the real thing.

In terms of process there's a big difference with tools like Swagger though in that you have to create the tests and corresponding implementation before you can start integration testing consumers, which might be tricky if you have multiple teams working on new services. I guess this is only really a problem when you're starting out as the tests and implementation should be ready soon after.

If we just use this for testing I was also wondering if you would use this at the beginning of your project or would you add it when the test suite start slowing down?

> What if when building a service, the pipeline also created a virtualized version of the service as an artefact?

Yes, interesting idea! I guess it does mean that there is a "testing contract" with the consumers? ie. the consumers need to know what example cases they can depend on in _their_ tests?

It's powering huge infrastructures as we speak; Twitter, Airbnb, and many others: http://mesos.apache.org/documentation/latest/powered-by-meso...

FYI: this link gets me into a redirect loop (probably because of something NoScript related)

It changes your deployment "atom" so instead of deploying compressed artefacts, you deploy containers. This has some advantages in itself (eg. it makes it easier to do gradual upgrades of your full stack, and you can run containers side by side on the same host), but is especially nice in combination with Mesos and Marathon which enables you to scale out horizontally across your cluster.

For Puppet you can use a validation script and a git commit hook to shorten the feedback loop on syntax errors: http://spoop.net/devops/2013/11/12/validate-puppet.html

The forking is not noticeable on today's machines; especially on this rather small scale. And yes, I would say that typing "cd `bm log`" is more cumbersome than typing "cdbm l". cdbm does pretty much the same behind the scenes anyway (with some error and argument checking), so why worry about that one extra mini process?

Hey! I'm the writer of these tools and was kind of surprised to run into it here, since I have not posted about this before — the submitter must have been an adventurous PyPI visitor ;)

This particular tool was mostly written to replace all the ad-hoc aliases and symlinks with something that could be easily maintained and brought to other commands (eg. cdbm, lsbm, mvbm, cpbm, etc.). To speed things up some more there's also tab completion and prefix matching, which is pretty convenient IMO.

It's different in that it's less cumbersome to maintain and that you can do more with the bookmarks than just 'cd' to it. For example, some other commands that are included are lsbm, mvbm and cpbm, which allows you to resp. list the files in a bookmark, and move or copy files to a bookmark. It's overall a lot more flexible and easier to extend common commands.