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.
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.
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.
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!
> 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?
Hi, I am the author of the blog post. The theory would be that your service is well tested enough for the produced simulation to give the majority of scenarios that you would need for tests in the consumers. I agree that perhaps there is a missing link in the consumers not knowing in advance what to call to produce certain outcomes - perhaps Hoverfly could interpret the JSON and display a contract with possible requests responses in the UI. This would be something easily understandable for a developer so they can quickly write their tests against it. Another choice would be to use something like swagger as a source for JSON rather than the service itself. This would be good for contract driven development.
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?
Last time I checked very few of them relied critically on Mesos (Twitter, some parts of Netflix, and Airbnb did IIRC). Most are just test deployments or non-critical applications. (e.g. I know Ebay and Paypal are also OpenStack users because they try all the new things).
Other than those, none of those are really huge companies. I have nothing against Mesos, but I hate overhyping something when it's still clearly in an early adopter phase. The side effect of overhyping is that the tooling isn't mature/simple enough for less ambitious people so they get a bad association with the project because they tried it too early after someone implied that it was mainstream already.
