An alternative to big switch handler for messages.

Using command pattern with action and role in the json.

Gangnam style is playing I'm the background :-D

We want to support maps, arrays, strings, numbers, maybe binary data? Maybe streams?

We don't want an API just to remote distribute the model. There is something wrong with this journrujourney, something isn't working.

Well, are they? I can't help but feel he's driving at something.

Do we need inheritance? Can be good, but we can't serialise classes and distribute them.

Do we really need accessors?

Encapsulation is good.

What is an object?

I've seen @matteocollina speak before, so I'm looking forward to this. #muCon2015

Links.

:-D

Some useful things to check out for preparing for failure and recovery. Particularly interested in symptom based monitoring.

Apparently healthcare.gov used CNN as their monitoring! #muCon2015

Hell yeah!

Architecture is about risk management.

This is probably the best way to move to microservices, they is, not necessarily moving to them. Allow your team the opportunity to evolve to microservices by giving them autonomy and room to experiment.

Ha! #muCon2015

Focus on products, not projects.

Lol about manifesto

Microservices from a business and people point if view.

You can check it out here.

Difficult to commentate a code demo, but probably worth following these guys/poles on twitter etc.

I'm no Java developer, but Java 8 looks quite bearable :-)

We're going to code BAAS (beer as a service) #muCon2015

Promising title for the next talk.

I think Guarav just invented the word "updation". #muCon2015

True. Good architecture can exist in a monolith, just like we have seen bad architecture (many times over) in a microservices approach.

The manifesto they developed. Pretty similar to how we work at the Mail Online. Particularly keeping management tools and ceremonies to the bare minimum. I agree that stand-ups are a distraction.

The problem with rockstar syndrome.

What happens when your rockstar quits.

This was for a big project for a company called Bridj, an Uber like bus service in Boston.

Consulting does not sound as good anymore.

Next talk by Guarav Gaglani

Advocates PRY rather than DRY for internal libraries to reduce dependencies between services. He says it makes it easier to burn code to the ground to rewrite without dependencies.

Don't enforce standards, offer good tools and solutions that are easy to implement. Evangelise solutions rather than force them on your team.

Don't be afraid to sacrifice, and justify this sacrifice to management. It's more wasteful to keep a lane piece of software hanging around.

Aim for the quality you need. The highest quality is expensive and often wasteful. The first iPhone is a good example.

Operating your own infrastructure is very costly.

It isn't, the responsibility needs to be shared with developers. Embrace extended devops for all teams.

What have they learnt.

And now what they have.

Nice photo of a monolith.

New talk with Erik Lindblad. This talk is about scaling from 12 engineers with a monolith to more than 300 with a microservices based architecture.

We must remember that microservices are potatoes, not apples. #muCon2015 @netkernel

And with enough of these spaces, you can build anything. All if these nodes are completely uncoupled. He's got about 1000 services, and 4000 endpoints in his system.

We only have to think about 3 things, spaces, requests and endpoints.

I'll let the slide speak for itself, but basically HTTP may not be the best protocol for microservices.

Microservices are not the actor pattern. They are something new and different. #muCon2015

A composite is greater than the sum of its parts.

Peter holding an "earth apple". Lovely metaphor about different cultures attaching existing perceptions to new ideas. Many people view microservices through the lense of what they already know.

Next talk by Peter Rogers.

Lol, there's a link for ball gags. #muCon2015

Remember, there is a level of pain you have to go through, before the pleasure kicks in.

People rarely read about microservice patterns before starting out.

Documentation should be a solved problem, but we seem to reinvent the wheel every decade. Swagger seems to be the best of a bad bunch.

Ugh, this doesn't deserve an explanation.

How do you find a service?

The drivers for moving to a microservices architecture. Social and technical.

Standard microservices problems.

It's difficult, it's painful, so why are we doing this.

This talk looks interesting! #muCon2015

*nods head* (I have no idea what's going on)

Hmm... Indeed.

This guy is forced to rush as he planned a 1 hour talk and he now has less than 30 minutes. Consequently I have no idea what's going on.

It's the 23 Ps... I mean 6.

New talk.

Demo! Ok that was pretty cool. Node goes down, node comes back with its state.

He's just been told he's running late. This guy can talk.

Docker plugins.

Diagram of how Flocker works. Notice the more politically correct version of master/slave.

Flocker treats a container and data volume as a single atomic unit. We're almost at the demo :-)

And this is the part where you specify your resources.

A Marathon manifest.

Plus you can write your own frameworks.

Mesos will manage resources while a framework does stuff with those resources. Mesos isn't about containers, you can run anything with it.

Stateless things are easy to containerise, but stateful services get left out. Now Kai is going to demo how you can do it.

These tools handle many jobs across many machines.

Kai has promised to demo us an automatic recovery of an microservice with state intact.

Scheduling is like a giant game of tetris, but hopefully when you get a row, the servers don't all disappear.

Forget about your hardware, use an orchestrator.

Containers are great at handling processes, but what do we do about the data. If a node has its own data and goes down, what happens to that data.

Each service will be unique and want it's own database that fits the purpose. This is going to require more processes.

Trying to solve the state problem in docker containers, or any cluster.