The Twelve Factor App model suggests that each service exports HTTP as a service by binding to a port, and listening to requests coming in on that port. In a local development environment, the developer visits a service URL like http://localhost:5000/ to access the service exported by their app. In deployment, a routing layer handles routing requests from a public-facing hostname to the port-bound web processes. This is typically implemented by using dependency declaration to add a webserver library to the app, such as Tornado for Python, Thin for Ruby, or Jetty for Java and other JVM-based languages.
Jun'2015: Takeaways after a Randy Shoup presentation
- every MicroService should have control of its own persistence (e.g. run its own Data Store - though it's possible you have a separate team running datastores-as-a-lower-level-service)
- every MicroService is owned/controlled by 1 team (might be ok for a team to control more than 1 service) (applying Conways Law)
- this is not for a Start Up (Growing Your Startup Tech Product Team) - until you have >10 devs (maybe more than 50!)... (Martin Fowler: Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.)
- the overhead of getting good at running services with consistent scaffolding is a net loss
- you probably still have enough uncertainty/flux in your Business Model that you'll be re-architecting your software, which is that much harder once it's been fragmented into services
- update: Fowler on Trade-Off-s.
- You can have stand-alone components in your monolith, just not the Rails Way... Decouple your logic from the actual framework, ship independent components in gems and introduce interfaces between your layers. This is only possible if you actually have abstractions, which could be service objects, endpoints, view models and higher-level abstractions. (Ruby On Rails)