One of the sessions on microservices which has been doing the rounds the last week was a talk by ThoughtWorks CTO Rebecca Parsons at QCon in London. The overall message behind Parsons’ talk was that whilst adopting microservices has become extremely popular, it needs to be approached with caution. The talk explores the relationship between evolutionary architecture and continuous delivery and how they allow for microservices and accompanying data architecture to evolve and efficiently work together.
What Parsons talks about here is applicable whether you are starting from a monolithic system that you want to break up or if you are starting with a monolithic problem that needs breaking up although she doesn’t talk about how to retrofit microservices into a legacy application as from a design perspective, Parsons says it really doesn’t matter whether you have an existing system or not.
For adopting microservices from scratch, Sam Newman, ThoughtWorker and author of Building Microservices, posted an article on Microservices for Greenfield. The article was written off the back of a colleague working on a project and the discussion of whether to start off monolithic or with microservices for a greenfield project and the trade-offs of each.
The piece looks at pin pointing service boundaries in order to keep a reign on cost of change and ownership as well as the deployment model for which, in this case, the client was open to cloud deployment which made microservices quite a good fit.
Other considerations included technology where the project presented third party integration with C and Java libraries which could be left to communicate separately with a faster Ruby based stack, given the stability of the existing third party libraries and also ownership, which looks at how the client is able to take over the solution in the longer term.
The context for another blog post by Venture Investor Lenny Pruss is the question he says he gets asked the most, “sure, microservices, distributed architectures and containerisation might make sense for the Googles and Facebooks of the world, but what about everyone else who doesn’t operate at Web scale?”
Jumping right to the end of this piece, Pruss suggests that one of the things that will come out of microservices is the creation of many companies that will address the challenges around microservices from a behavioural point of view, providing organisational tool kits for managing people and processes.
An organisation that seems to have nailed microservices (and was using Docker containers before 1.0) is Gilt. Nailed in the context of Gilt mean three things – growth and the creation of self contained teams with developers that are empowered by a sense of ownership, quicker response times for requests and issue resolution plus the reduction of risk in bringing down an application when something goes wrong.
For microservices with Python, Armin Ronacher discusses Nameko, a framework designed to help create, run and test microservices. Nameko is useful where support for parallel execution in Python has been poor and allows you to build individual services which Ronacher says can emit events to which other services can either subscribe to or directly invoke each other via RPC.
This post is a walk through for using Nameko from defining a basic service to a shell helper that launches an interactive Python shell for RPC access through to events where services want to collaborate on activity. The post also looks at dependency injection, concurrency and parallelism and overall Ronacher describes it as probably the best open source solution for building a platform out of small services in the Python world so far.
Arduino also talked about their ecosystem shift which included the adoption of microservices in a blog post a couple of days ago. Arduino used the Arduino Day website as a testbed for achieving a series of goals including 99.98% uptime, high speed across devices with the adoption of microservices.
Having undertaken a small program of bug fixes for their legacy systems, Arduino are now adopting Go for microservices allowing them to create REST APIs quickly although their database is still playing catch up and the decision has not yet been made for which data base to port to. Arduino are very much mid journey and have not yet chosen a cloud provider for hosting but for the front end are now using Angular.
