danielbryantuk

We put together the Kubernetes Developer Learning Center for folks looking to bootstrap their k8s hands-on experience: https://www.getambassador.io/kubernetes-learning-center/

Combined with the K8s official docs https://kubernetes.io/docs/home/ and GCP getting started guide, this will give you a good tour of the tech: https://cloud.google.com/gcp/getting-started

For a general overview of DevOps and the principles behind this, you can't go wrong with reading "The DevOps Handbook" and researching the "Accelerate" metrics

I wrote a blog post a couple of weeks ago that may answer some of your questions:

https://www.specto.io/blog/recipe-for-designing-building-tes...

In answer to your specific questions

#1 If you are testing system-level (end-to-end) functionality the separate repo definitely. If you are testing service (component) level functionality then store tests in the same repo as the service and virtualise/mock dependent services

#2 Opinions in the industry are split here - Adrian Cockcroft often suggests using client libraries (as do the Datawire.io team), but I don't always because of the developer maintenance cost of these libraries (and forget it if you are using multiple/polygloy languages in your stack).

If I understand your question correctly I think you would benefit from reading about Consumer-driven Contracts, as this will help you detect contract/API breaking changes

#3 You can either entrust your build pipeline to manage this (I've used the Jenkins promotion plugin to do this kind of thing), or you can use yaml config files to specify service runtime dependency requirements (kind of like Maven or Ruby Gems etc, but at runtime), or if using REST/HTTP you can deploy two service versions at any given time and user the 'Accept' request-header to specify which versions of services can communicate with each other

Feel free to DM me if you have any further questions!

Adding 'seams' into the monolith (and exposing this typically via REST or AMQP) is the most effective way I have found.

The alternative is to 'screen scrape' the data returned from calling the monolithic application via the interface exposed now. For example, calling a website page, parsing the HTML data returned, and extracting what you require. However, the code/algorithms you have to write are typically complicated, and the resultant code often fragile and highly-coupled

I'm the article author, and it's great to hear your feedback! I've published a couple of other articles that may help with the topic of microservices:

https://opencredo.com/javaone-building-a-microservice-develo...

https://opencredo.com/the-seven-deadly-sins-of-microservices...

I'm also looking for more suggestions of how people will want to use Hoverfly with Java projects, and so please do give me a shout via twitter @danielbryantuk if you have any ideas!

I agree - I'm seeing some application frameworks even encouraging developers to expose CRUD functionality via REST (Spring Data REST, I'm looking at you)

There may be a few narrow use cases where this is valid, but in general we really should avoid doing SQL joins over HTTP :-)

As Stefan argues in the talk, one of the original sins with SOA was caring too much about the services (and potential "reuse"), and forgetting about the notion of offering a cohesive piece of business functionality i.e. a bounded context with well-defined responsibilities

Thanks for the response. Yes, the article was primarily a summary, but it included content not available in the slides

Can I ask why you changed the link please? The original linked document provided commentary on the slideshare slides (and also linked to them)?

In my experience working as a consultant across multiple organisations, not enough people have been doing this.

As for a putting a name on it - a name can help spread the idea (ubiquitous language and all that), but it can lead to abuse and cargo-culting.

I believe a label is often helpful during the 'innovation' and 'early adoption' diffusion of innovation phase, and this is firmly where mobbing is at the moment

Great comments Daniel, and I think you've touched on one of the key points that we're seeing with the rise of mob programming and lean practices etc "it's really completely re-structuring what we think about when we think about a tech team delivering value"

This is the sticking point for many people, as we still like to draw analogies between coding and typing, or coding and physically building structures (which inherently are limited by the application of manual labour), rather than seeing it for the value-creation/design-thinking act that it actually is (and accordingly the need for good imagination and decision-making abilities)...

Wow! I couldn't have said it better myself. Having worked across a variety of codebases and teams over the last 10+ years, it has become obvious to me that delivering software is an inherently social activity (at least the delivery of valuable software)

IMHO, the reason we've seen the rise of XP, Behaviour-driven Design (BDD) and DevOps is that each part of the software delivery community is gradually coming to this conclusion within their own realm

Mobbing for me just makes sense on so many level, especially from the point of view of adding 'expertise' to a problem/solution:

Not sure on how to integrate the latest language feature into your code - bring someone with experience into the mob...

Not sure how this feature could be tested - bring a QA/tester into the mob...

Not sure of the infrastructure requirements of this new database - bring an operator into the mob...

+1 to the comment here.

I see lots of discussions after code has been cut ('why this design?', 'why this library?', 'did you consider this?'), which would have been much more valuable to have as the code is being written.

With mobbing I'm thinking you can answer these questions and discuss opinions at the most appropriate time in the software creation lifecycle...

I think this reply thread is confusing the specific, i.e. the technique of 'mobbing', with the general, i.e. the (mis-management) approach to fixing issues with 'all hands to the pumps'.

The only thing the Unruly team is dogmatic about is delivering valuable software. The techniques they talk about are simply this - techniques.

In my work as a consultant there is rarely a 'one-size fits all' technique to developing a feature, but knowledge of several approaches is very valuable.

This is the purpose of the article - to allow you to consider the addition of 'mobbing' to your existing approaches of single development and pairing

Looks awesome (and great graphics on the site)!