|
Hi I'm the author of this post and thanks for the feedback, just wanted to make a few comments... 1. Half baked
Not sure I think this is a fair comment, it implies a lack of care, I do however think that work in progress is a fair assessment and actually I state this myself, the approach taken is an evolutionary one. With every use, identify improvements and make them so next time things are better. The more we share our learnings the faster the industry will advance and to many Microservices patterns are still a new approach, there are huge learnings to be had, some from personal experiences other from avoiding the failings of others. Just trying to share what I know in the hope it might help someone else. 2. Dependency Injection
I was fairly confident this is a marmite (love or hate) approach with Go, there are some threads out there longer than the complete works of Shakespeare arguing if it is needed or not. For me it helps with decoupling when taking a test first approach and this is the main reason I choose to use it as a pattern. I have written services with and without DI, I definitely prefer with, I did say it was opinionated :) 3. Service Discovery, Failover, Storage, etc
This is a huge topic in itself yet from people I speak to when discussing Microservices is something that often comes up. I personally hope that service discovery will be picked up at a Platform level by Mesosphere, Kubernetes or new PAAS providers like Docker Cloud or Google Container Service. At present I am using Consul, Consul Registrator, and HA Proxy but the bigger and more complicated the system the bigger this problem becomes and I am not 100% happy with things in this space. Storage is best avoided where possible, Docker certainly introduces problems with mutability, S3 is an option at the moment for shared storage but there are interesting things in the works with Docker Volumes. Event Sourcing is another huge area for Microservices, effectively decoupling them removes many of the problems around failover but this in itself huge complicated area. In general developing for failure is a good approach, deciding how things fail should be a cross functional requirement when discussing the features. 4. Feature Toggles
Good call and in fact at my day job we use these extensively, in fact we could not deploy without them. At the moment this is not a problem I have had to tackle and therefore have not added this feature. I suspect this is something that will affect me in the future once I move from writing new services to changing and maintaining existing ones. Feature toggling in microservices opens up a completely new approach, do you toggle in the service code or with a different copy of the service itself and toggle within the service routing? Really appreciate all the comments, I have certainly learned some stuff and I'm really looking forward to where the industry will head in the next 12 months. Nic |