Whats mighty about Micro-services?

As modern applications continue to grow in their monolithic form they are starting to bend and break when it comes to the issue of scaling. Not to mention the long deployment time.
But what is a realistic, pro-active way to improve your app that will ensure its longevity, scalability and also offer lots of other rewards..We take a look at the MICRO-SERVICE.

Screen Shot 2015-06-19 at 21.59.07

What is it?

Do not confuse them with Web Components which are something completely different.
Essentially Micro-Services are a software pattern where an app is split into components which are hosted on separate endpoints. Each endpoint is its own application (possibly MVC) which returns markup (and assets) for that component. They can be written in any language or framework based on preference and tend to run over HTTP, normally returning a JSON object containing component markup.
With something like Amazon cloud it is very possible to use public EC2 instances to host components.

Whats good about it?

Major application is split into smaller components which are separately deployed units.
Micro-service applications are more robust, have more scalability and better at Continuous Delivery. Specially if they are paired with Amazon cloud, as they could potentially be deployed within a minute.
Any changes are limited to specific service components so no longer any “Big Bang” releases, which nobody wants right.
Testing is made easier as regression test can be done on each service in isolation.
Due to the distributed architecture complexity is now separated. Different patterns in different services.

Whats bad about it?

The biggest issue with it seems to be performance. With several requests for different HTTP endpoints performance is bound to be take a hit. However with clever caching this can be solved. Not to mention the use of versioning and cache busting.
Assets are not easy to solve in this architecture as each component will have its own CSS and Javascript. There are some nice solutions mentioned later on for this.
It can be very difficult to share items across components..however it can be done. I have found using a component library which is shared by all the micro-services is one way.
Knowledge sharing across components is next to impossible, however a well designed component will not need much given to it. Will will be self containing.
This brings us onto the last issue of sending data to the component. So far the best solution to surface has been using a query string and the component fetching the rest from elsewhere.

Asset issue and potential solution

One of the issues mentioned above is the issue of how to serve assets. If the endpoint returns them they are easily inlined in the parent app but with many components in a page the page weight will suffer.
The Financial Times seems to have found a tidy solution in…bundlers.
Effectively there is a Bundler component which exists. A request is made from the parent application to the bundler with component assets required.
The below is asking for the components it is using assets (if using component one, version 1.0.1, than ask for those assets)…in format ‘component_name@version’.
- 1 endpoint for css
- 1 endpoint for javascript

/bundler/js?one@1.0.1,two@1.2.1.js
/bundler/css?one@1.0.1,two@1.2.1.css

This means that the bundler deals with building the assets into a single feed as well as the caching. But updating a version will act as a cache buster and will therefore make a new request and build the new asset feed.
This way there is only 2 extra page request for the parent app.
Simple and elegant.
How you develop the Bundler is another thing entirely but is not tricky once you have this bases and an asset endpoint for each component as well which the bundler will use.

Who else is using Micro-Services:

My favourites:

BBC Radio & Music
- use symfony components based on PSR-0
- PHP+Apache+Composer
- have slim and flexible skeleton they have built which all components start with
- using amazon AWS
- single URL for markup and single for assets.

Financial Times
- Origami ­
- https://github.com/Financial­Times/ft­origami ­
- http://origami.ft.com/docs/component­spec/web­services/
- No css/js inline
- have file versioning and cache buster for

Couple of others:

Lonely Planet ­
- http://ianfeather.co.uk/a­maintainable­style­guide/ ­
- http://ianfeather.co.uk/what­we­would­change­about­rizzo/#let­the­component­manage-
its­own­assets
- Only header/footer component served over http

BBC News

https://github.com/BBC-News/chintz

- seems to rely on assets served inline

BBC Sport ­
- components/templates with Morph
- heavily component driven
- https://github.com/bbc­sport/ShouldIT

GOV.UK

https://gdstechnology.blog.gov.uk/2014/12/11/govuk­living­style­guide/

Overall

I have found that the pattern produces isolated testing, deployment and helps manage complexity and Continuous Integration. After speaking to many individuals using this pattern it seems the positives out-weight the negatives and it is something people can not stop raving about.

Leave a Reply