There is a cost associated with larger code base. Cognitive cost that translates into a time and monetary cost.

The business case for microservices.

New talk. Ian Cooper from Huddle.

Sounds crystal clear.

Chapel is apparently a language, good for number crunching. This is calculating pi.

Pi as a service in python.

Flow is made up of these.

Russel Winder. Looks like a fun guy.

Lol. New talk on architecture.

Like this, and so on. I'm not going to post all of this. I'm sure there are good resources online.

Marathon offers a REST API for application resource management.

Mesos abstracts away your resources and boxes I think. Used in Apple, Airbnb, Netflix.

Not using any of these but I suspect we have developed our own solutions to the same problems in house.

This is true too.

Not an exhaustive list, but it'll help. I can definitely agree with automation.

And after?

New talk. Conduct your microservices. Before?

Developer philosophy at #muCon2015

We can apply UX concept to API design.

Understand your developer users. Who are they and what to they need. Do they still use SOAP, for example :-)

So this is about external APIs, why should you expose an API and why should you make it lovable. One reason is because devs will evangelise your product.

Looks like I'll have to wait for the guitar solo.

Back from lunch and this is already looking exciting. #muCon2015

Lunch! Kinda strange, but I like it.

API Blueprint uses markdown to specify your API spec, for some reason.

RAML API Designer. Very similar to Swagger.

Swagger in use.

He seems to be pointing us toward Swagger.

These are the full featured API tools he's been using.

What we want in a documentation tool. Using a tool also encourages you to think about all these things. I also like the idea if these extra features too.

The zen of REST API documentation.

Summary: The end reality is a lot more involved than a simple docker container. #muCon2015

Or better yet, use splunk.

Monitoring and logging for hundreds of services. This needs to be collected, aggregated and stored for analysis (ES or kibana).

And now for inter service communication. He's advocating etcd over zookeeper for service discovery.

I wish this guy would put words next to the logos. Docker swarm?

And then that all goes into AWS, right? After 100 clicks and two days, it's all up there. But then you want a staging and integration environments. With a handful of tools, they automated the process. But what about horizontal scaling?

Just put it all in docker, right?

This looks promising.

Vertical point of view vs the horizontal. We can test this by looking at the data that goes in and out between these streams. Don't test the process, but the data.

Flow oriented microservices is an events based approach that models how people/clients think about their application logic.

Docker-compose makes another appearance.

Or create entire mock processes, which is a lot bigger to sort out.

Options for doing mockist TDD with microservices. You can create client libraries to mock out your other services.

The London school of TDD (mocking TDD) tests the communication between dependencies, rather than the result. This ties in nicely with microservices.

Manual testers have a hard job, and they don't get enough respect. It's a tough job. #muCon2015

We use the network as a boundary between microservices, and the network hates you. #muCon2015

What is architecture vs design. There are limitless designs, but only a few architectures. Architecture is your philosophy, it's the route you take, the tools you use to find a design to solve your problem.

Nobody can agree. But there are a couple of things everyone agrees on. Isolation and aspiration. Isolation of contexts/functionality/responsibilities and the aspiration that things will be better if we can just get this right.

This looks familiar.

Stubbing out services to get started.

Next talk.

Why 300?! Size is irrelevant says the presenter. You should be focused on cohesion, does the code belong together. Might as well ask how big an object should be. Think about it in terms of rewritablitity, could you rewrite it in a month. This tends to lead you reasonable service boundaries. Don't be afraid to burn to the ground and start again.

Debugging is tough in microservice architecture. Bit we gain independent scaling, independent failures.

Until you have to.

Keep it single threaded, that's convenient for node.

HTTP is for communication with clients, events are for talking between services.

Open VMS is an OS that was about 2 or 3 decades ahead of it's time. #mucon2015

What we are missing in a monolith is independent deployment.

Most successful software is a big ball of mud. Apparently there is a paper you can read on this.