TECH//CONNECT EVENT: LESSONS LEARNED

Tuesday 9th August 2016

Share to:

Microservices is on lots of people’s minds and for all sorts of different reasons. Andrew Rea, Chief Application Architect at the DWP, gave an excellent presentation titled “From Monolith to Microservices”. It was followed by a really engaging and interesting Q&A from some of Leeds’ leading technical people from the likes of EE, ITV, EMIS and BJSS. Below are a few key points taken from this part of the evening…

What are Microservices?
Microservices are a more concrete and modern interpretation of service-oriented architectures (SOA) used to build distributed software systems. Like in SOA, services in a microservice architecture are processes that communicate with each other over the network in order to fulfil a goal. Microservices is essentially an architectural style composed of good design practices and principles that are certainly not new.

I’ve invested in SOA, now what?
Well that depends on you and your business. SOA is ambiguous and means many different things to many different people. What microservices offers is a concrete approach to designing software for single service use in order to offer greater consistency and could even be superset as part of a larger SOA implementation.

How micro should Microservices be?
Without wanting to say how long a piece of string is, it really depends on what service you want you offer. Some will say it should be 2000 lines of code or less, the team should be made up of no more than eight people or that you should be able to rewrite it in two weeks.

What do the above points raise in your mind, does this scale seem feasible to your needs?

Key points

•Don’t do microservices for the sake of it. Ask yourself how does it make me, my team and my business better? If you can’t answer those simple questions, don’t do it!

•Give each service its own source repository. It’s much easier to set them up from the beginning than going back and untangling all your code.

•Separate your services by business capability. Instead of having one service for multiple business domains, give each domain its own service.

•Automate as much as possible in order to deploy, operate and maintain your microservices.

•Test, test and more testing! Working at a microservices level gives you the opportunity to test smaller and more often, take advantage of this fact.

•Don’t over complicate things, stick to good design practices and principles!