At the API Academy #api360 Microservice Summit event, held in New York City, a collection of microservice experts presented their thoughts on the current state-of-the-art of microservices and associated architectural and organisational issues, process and technology. Key lessons learned included the need to invest in supporting technical and organisational infrastructure to fully take advantage of microservices; care must be taken to understand the principles of microservices being focused around business capability and self-governing accountable teams; and that development and operations teams must understand the practice of building and running robust distributed systems.
Matt McLarty, VP of the API Academy, opened the event by drawing a comparison between the development history of automobiles and microservices, stating that although a car was initially only of interest to hobbyists, the introduction of the assembly line made this affordance available to the masses. It could be argued that Docker is providing an analogous means of mass production for packaging applications within Linux containers. McLarty continued the analogy by stating that the widespread adoption of cars was only successful due to supporting infrastructure, such as interstate highway maps, traffic lights and gas stations, and argued that we still need to develop equivalent infrastructure to truly realise benefits of microservices and container technology.
Ronnie Mitra, Director of API Design at the API Academy, presented several definitions of ‘microservices’ from industry luminaries, and proposed that that may be too much focus on the ‘size’ aspect of this architectural style. Care must be taken to avoid “simply pushing complexity around” the system, and architecture and design must be conducted at both macro and micro levels. Mitra stated that service boundaries are the most important concept within a microservices architecture, and can assist with managing the pace of evolution throughout a system. Organisational design and culture play a large part in the successful implementation of microservices, and although there are constant trade-offs between speed and safety within software development, the segmentation provided by microservices may allow increases in both if done correctly.
Holger Reinhardt, CTO at Haufe.Group, presented ‘The Automated Monolith’, and told the cautionary story of an almost failed migration from a monolith to microservices. The initial attempt to migrate a monolithic application resulting in a host of issues that included lost test coverage, scope creep, increasing project complexity (a leading indicator of which is telling management “we just need X more developers”), and “agile becoming fragile”. Upon retrospection Reinhardt was reminded of two important concepts, first, Martin Fowler’s prerequisites for microservices, most of which centre around automated; and second, the concept of ‘stabilise, optimise and transform’ from Lean. An additional migration attempt was performed with the same team, but with more focus on automation, prioritising the migration of the parts of the system that required ‘increased speed of change’, and by increasing the project management structure (“waterfall-agile” as a bridge towards true agile) and championing the required leadership. This second migration has resulted in success.
Next Vijay Alagarasan presented an informative list of “Seven Microservice Antipatterns”, which has been published previously on InfoQ:
- Cohesion Chaos - services must align clearly to a business capability and should not try to do something outside of their boundary.
- Not taking Automation Seriously - Continuous deployment, if you have not done so, is a must investment and a cultural change that every enterprise should aim for
- Layered Services Architecture - Creating multiple, technical, physical layers of services would only cause delivery complexity and runtime inefficiency.
- Relying on Consumer Sign-off - instead every service that you deliver must have a test suite, which should cover all the service functionality, security, performance, error handling, and consumption driven testing for every current and future consumer
- Manual Configurations Management - Used application configuration management tools as part of a PaaS or continuous deployment
- Versioning Avoidance - Have a versioning strategy that can allow the consumers a graceful migration and assure providers can transparently deploy changes without affecting anyone. Limit the number of side-by-side major versions in the production and govern them.
- Building a gateway in every service - Invest in API Management solutions to centralize, manage and monitor some of the non-functional concerns and which would also eliminate the burden of consumer's managing several microservices configurations.
The remaining session before lunch was a panel discussion moderated by Lou Powell, Principal at Vanick Digital, with several microservice experts that included Erich Ess, working at jet.com, Sangeeta Narayanan, Director of Edge Developer Experience at Netflix, Cassandra Shum, Lead Consultant at Thoughtworks, and Adrian Trenaman, SVP Engineering at Gilt.com. Key takeaways from the panel included hiring responsible software engineers and giving them the context, autonomy and accountability in order to deliver effectively; driving innovation and stabilisation of systems, tooling and processes by the use of the ‘pioneers, settlers and town planners’ model; increasing collaboration between the business stakeholders and IT; developing and nurturing an effective culture of transparency, shared understanding and cooperation; and planning and implementing for failure throughout the technical stack and organisational system e.g. circuit-breaks and ‘disaster in recovery training’/gameday sessions.
Mike Amundsen, Director of API Architecture at API Academy, began the afternoon sessions by stating that innovation is everywhere, and demonstrated the importance for companies to be able to innovate rapidly by quoting Joseph Schumpeter that “innovation is the dimension of economic change”. Amundsen stated that by dividing work and cooperating to solve problems (much like ants do), we may be able to innovate more rapidly. The microservice architectural style may help us realise this vision within software development. Quoting from work documented in ‘The Fifth Discipline’, Amundsen argued that we need to build learning organisation, where experimentation and the potential for learning from failure is encouraged. IT teams should be given time to look towards the horizon and experiment with new technologies, as this may allow the associated organisation to continually innovate and ‘jump the S curve’ company growth cycle.
Erik Wilde, Principal Consultant at CA technologies, presented “Microservices and Web Architecture”, and argued that the many people consider SOA a “bad word”. The initial implementation of web services were not created in the spirit of the world-wide web (WWW), and focused on system architecture rather than ecosystem architecture. Microservices can be seen as the next evolution on SOA, and combine the original principles with agile, continuous delivery and DevOps. Wilde suggested that microservices may offer “speed and safety at scale in harmony”, but there currently are several “blind spots”, such as how to find services in a large ecosystem (where potentially some kind of decentralised directory is required), and how to design, manage and evolve microservices so that the landscape is robust and flexible. Wilde concluded the talk by presenting the “three Vs of microservices”: volume - how can an overview of the system operating at scale be obtained?; variety - how as a creator or consumer should different service designs be handled?; and velocity - as the landscape evolves, how stable are services and their design?
For the next session Mike Amundsen interviewed Mel Conway, creator of “Conway’s Law” for ‘Sixty Years of Humanizing the Craft’. Advice presented included: ‘partition the solution’ - expressive domain-specific intermediate languages give the combined solution a lot more “bang for the buck”; ‘static is good’ - making application development accessible to a large number of people requires the elimination (or hiding) of algorithms; ‘simplify the developer’s life’ - give the developer immediate feedback, and don’t make the developer distinguish between ‘programming’ language and ‘execution’ language; and “humanize the craft” - event-driven applications and transform-in-place systems may be easier to conceptually understand than traditional programming, and the way to make application development universally accessible is to harness the hand-eye-brain system with appropriate tooling (much like using a potter’s wheel).
At the penultimate session Jon Moore, Senior Fellow at Comcast, presented “Surviving Partial Failure in a Microservices Jungle”. Moore proposed that teams creating a microservice-based application are effectively building distributed systems, and these types of systems are prone to partial failure. A variety of partial failure types can appear the same to an initiating client, despite what processing has actually occurred on the called service, and therefore we must develop appropriate mitigation strategies. Moore presented three such strategies: (1) idempotent service interfaces - retrying a service call should not result in unexpected side effects. Effective caching of responses can also be utilised to reduce load on a service and hide transient errors (at the potential cost of stale data); (2) divide by criticality - use asynchronous communication, create appropriately defined services boundaries, and provide alternative (fallback) implementations; and (3) recombine where possible - favour coarse granularity of services to minimise partial failure, and learn to identify warning signs of services being overly granular, such as services with only a single client, tight coupling (any change to service A also results in a change to service B), and correlated calls.
The final session of the day, “Microservice Blind Spots” was presented by Irakli Nadareishvili, CTO at ReferWell. The adoption of the microservices architectural style has partly been driven by the emergence of container technology, which favours running single isolated processes. Nadareishvili argued that the current focus within the microservice community is overly code-centric, and instead the focus should be placed in service boundary interface design - “coupling of service interfaces is every bit as toxic as the code one, and can render an entire architecture useless”. Domain-driven Design (DDD) and the concept of a bounded contexts are useful techniques to help developers model business functionality within microservice-based applications effectively. Nadareishvili concluded his talk by arguing that event-based system design techniques, such as event-sourcing (ES) and command query responsibility segregation (CQRS) are very effective for developing microservice systems.
More details on the API Academy #api360 event can be found on the event website or the #api360 hashtag on Twitter.