anchor.diff:  
   API Management will be at the heart of many successful microservices setups. It unifies common functionality; provides a place to discover, register and manage services; reduces the scope for costly errors and inconsistencies; and, provides a natural barrier between internal and external where it can collect valuable metrics and audit information.
   
  -It was a pleasure to meet all of those developers who are interested in apiman - and it was particularly interesting to hear your use-cases. I would encourage you to keep giving us your feedback, as we use it to decide on features, priorities and to direct our roadmap.
  +It was a pleasure to meet all of those developers who are interested in apiman - and it was particularly interesting to hear your use-cases. I would encourage you to keep giving us your feedback, as it directly impacts our features, priorities and schedule.
  
positive.code: 
  == Services, services, everywhere!
  
  A microservices architecture encourages the decomposition of problems into small, isolated and reusable chunks; much in the same spirit as UNIX's _do one job and do it well_ philosophy. This brings with it a whole raft of benefits, for instance: we can scale each component independently, avoiding unnecessarily dragging along other components which just happen to reside in the same monolith; we can easily have a single team wholly responsible for a single microservice's lifecycle, simplifying debugging and allowing them to use their skills and technologies of choice; and, we can easily create new functionality via composition. However, this proliferation of heterogeneous services poses some challenges, a significant subset of which API Management is a key solution to.
  
  == Avoiding reimplementation of cross-cutting functionality
  
  A problem that can quickly become apparent is that key pieces of important common functionality are required that are difficult or undesirable to reimplement in every API. Good examples of this would be security concerns like authentication and authorization, or business concerns like rate-limiting, billing and auditing.
  
  It's quite clear why we would want to avoid this situation. Imagine we have hundreds of microservices we need to expose to the outside world; the nightmare scenario is that we have to implement complex and prone-to-change authentication and authorization schemes on _each_ of them. Quite aside from bloating and complicating our microservices, it is going to be extremely difficult to guarantee that each service has implemented all of this common functionality consistently and correctly - we could quite plausibly be leaving holes in our system simply by virtue of surface area.
  
  
negative.code: ---
  layout: post
  title:  "Microservices Architecture Day Appearance"
  date:   2015-06-15 21:30:00 +0100
  author: marc_savy
  categories: microservices conference talk
  ---
  
  I had the pleasure of presenting on apiman at the recent Microservices Architecture Developer Day, with our colleague Kurt delivering a short demo of our software running within http://www.fabric8.io[Fabric8]. It was particularly enjoyable meeting developers who are interested in, or are already using, apiman - so, thank you for your insightful questions both during, and after, the presentation.
  
  Given the packed schedule, there was a limited amount of time to explore apiman plus microservices, and hence this seems like a good opportunity to write a blog post expanding upon the themes I touched upon.
  
  