fritzvd

The microservices track came down to most speakers saying things more or less in similar vain, each talk having its own emphasis. Richard Rodger opened up and basically laid the groundwork for the microservices bit together with the Fred George talk.

After hearing the talks I’d define microservices as small blocks that can run independently and do one thing, along the Unix philosophy. Making building blocks in stead of one big application that does everything. Now instead of including this one small thing in the rest of your app, you run this as a single thing which returns results based on messaging.

Your services will be fairly stupid as in that they will not know about the other services. So in order to communicate with each other you have the services talk to a message bus.

What this enables is having:

• a naturally scalable application
• naturally scalable teams (as you don’t need to know about the whole system)
• polyglot applications without it becoming a problem

The nice thing about developing an application as a combination of microservices is it enables seperate small deployments. Versions of software can be bumped seperately and released seperately without the whole server having to suffer.

Now the implementation and how different microservices work together differs amongst the various speakers.

And of course different problems arise you now have lots of apps and servers to maintain, and you have to present this whole bunch of services as one application which feels like a wholistic thing to the user. According to Dejan Glozic this could be solved with what he called: local clustering. Clifton Cunningham put forward a few solutions for this: client side assembly, front end server, server side includes or edge side include. Or of course: build it yourself → Compoxure.

In this scenario every service hosts and returns it’s own rendered html (or json if you request that format). If a service dies, the cache will run the last known good html or the html renders a default.

For the static files part it’s similar. Every service knows which static files it needs and rakes them together with a tool called: Bosco.

The company Richard Rodger co-founded nearForm built a solution for the local clustering problem in their microservices framework Seneca, their objective is best explained in the project website.

Programming anarchist Fred George threw his own version in the mix, where he said all services receive all messages all the time. You can then categorize the message in his metaphor of Rapids, Rivers and Ponds. The rapids are the streams with all the messages. The rivers the themed events and the ponds things like state/history.

A service should be so seperate, you should even have all the microservices have their own persistence layer. If a service has 2 jobs, make 2 services out of it.

Microservices FTW.