# Who is using on production
**URL:** https://discourse.nameko.io/t/who-is-using-on-production/178
**Category:** googlegroup
**Created:** [March 20, 2017, 11:28am UTC](https://discourse.nameko.io/t/who-is-using-on-production/178 "2017-03-20T11:28:36Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Abhinav\_Sohani](https://discourse.nameko.io/u/Abhinav_Sohani)
#### Post date: [March 20, 2017, 11:28am UTC](https://discourse.nameko.io/t/who-is-using-on-production/178/1 "2017-03-20T11:28:36Z")
Hi All,
We have a Django monolith and planning to move to microervices
architecture. We came across Nameko and found it interesting.
Is there list of projects using nameko in production or case studies/
articles.
It would be great if any of you can share your experience with Nameko. How
you have architect it? How have you done authentication? etc.
Thanks
Abhi
---
### Author:  [@mattbennett](https://discourse.nameko.io/u/mattbennett)
#### Post date: [March 20, 2017, 5:59pm UTC](https://discourse.nameko.io/t/who-is-using-on-production/178/2 "2017-03-20T17:59:46Z")
Great question! Would love to see this thread grow.
I can kick it off --
We've been using Nameko in production at Student.com \<[http://student.com/>](http://student.com/>); for
~2 years.
In our setup we have:
\* Domain services, which look after the data and logic related to specific
domains in our business (we do student accommodation, so one service
manages properties and rooms, another handles prices and availability, and
so on)
\* Facade services, which aggregate several domain services into APIs for a
specific customer (e.g. there is a facade for our website, another for our
content management system)
Facade APIs all RESTful HTTP, and they call the domain services over RPC.
There's a fledgling example that shows this pattern
here: [GitHub - nameko/nameko-examples: Nameko microservices example](https://github.com/nameko/nameko-examples) (note the "gateway"/facade
service still in a PR).
For auth, there are two approaches I've taken in the past:
1. Authenticate at the boundary (i.e. facade) and have domain services just
trust their callers (simple, but weak security)
2. Also generate a JWT that contains permissions/roles for that identity,
and pass that along with every call so each downstream service can perform
its own authorization checks.
We should try to add auth into the example app. The JWT approach sounds
complex but it's actually quite simple.
I've already written about our ops/hosting in this
thread [Redirecting to Google Groups](https://groups.google.com/forum/#!topic/nameko-dev/Sfvm9xY6MHE)
Hope that helps. I'd love to see some other folks adding their experiences
here too.
> **···**
>
> On Monday, March 20, 2017 at 11:28:36 AM UTC, abhinav...@gmail.com wrote:
>
> > Hi All,
> >
> > We have a Django monolith and planning to move to microervices
> > architecture. We came across Nameko and found it interesting.
> > Is there list of projects using nameko in production or case studies/
> > articles.
> >
> > It would be great if any of you can share your experience with Nameko. How
> > you have architect it? How have you done authentication? etc.
> >
> > Thanks
> > Abhi
---
### Author:  [@Conor\_Seabrook](https://discourse.nameko.io/u/Conor_Seabrook)
#### Post date: [April 12, 2017, 1:13pm UTC](https://discourse.nameko.io/t/who-is-using-on-production/178/3 "2017-04-12T13:13:18Z")
We have been running Nameko in production for a little over a year now with
great success. We are a mobile game developer with a number of successful
games which are heavily server based. Being that we control both the client
and server our gateway/api uses http and the "experimental" websocket
service for two way communication.
Our setup:
\* Gateway which passes requests directly to services, and sends events out
to clients. Nginx handles ssl termination.
\* Currently we have 25 services spanning 15 compute nodes, at least 3
instances of each for HA and more for high volume services. We use Chef for
configuration management to quickly scale and deploy.
\* We use Redis as our main datastore backed by PostgreSQL. Redis writes
flow to our data warehouse via dedicated db services.
\* name\_sentry sends errors to our sentry servers for analysis.
\* Every entrypoint hit is logged to file and shipped to logstash with
fillebeat. We then grok the logs and push them to elastic search for
analysis. Having a central logging solution has been invaluable. We can
easily see all activity by a player's session or view all service calls
that made up a single client request via a correlation\_id. We use Kibana to
easily query these logs. We generate on average 5 Million hits per day, but
burst much higher.
\* Nagios/Ganglia to monitor everything including growing RabbitMQ queues.
\* Gitlab continuous build integration to easily push service code to
production.
Overall moving to microservices was the right decision for us. We looked at
rolling our own solution as well as a number of other frameworks but in the
end landed on Nameko which has been a joy to work with. We had a rather
huge Django/Celery/Twisted application which was becoming increasingly
difficult to work with, and easy to break. So we moved to micro services
and never looked back!
> **···**
>
> On Monday, March 20, 2017 at 7:28:36 AM UTC-4, abhinav...@gmail.com wrote:
>
> > Hi All,
> >
> > We have a Django monolith and planning to move to microervices
> > architecture. We came across Nameko and found it interesting.
> > Is there list of projects using nameko in production or case studies/
> > articles.
> >
> > It would be great if any of you can share your experience with Nameko. How
> > you have architect it? How have you done authentication? etc.
> >
> > Thanks
> > Abhi
---
### Author:  [@Abhinav\_Sohani](https://discourse.nameko.io/u/Abhinav_Sohani)
#### Post date: [March 24, 2017, 3:18am UTC](https://discourse.nameko.io/t/who-is-using-on-production/178/4 "2017-03-24T03:18:57Z")
Hi Matt,
Thanks for sharing the details. It has given me the fair idea.
Looking forward to auth example.
Thanks,
Abhi
> **···**
>
> On Monday, March 20, 2017 at 11:29:47 PM UTC+5:30, Matt Yule-Bennett wrote:
>
> > Great question! Would love to see this thread grow.
> >
> > I can kick it off --
> >
> > We've been using Nameko in production at Student.com \<[http://student.com/>](http://student.com/>); for
> > ~2 years.
> >
> > In our setup we have:
> >
> > \* Domain services, which look after the data and logic related to specific
> > domains in our business (we do student accommodation, so one service
> > manages properties and rooms, another handles prices and availability, and
> > so on)
> > \* Facade services, which aggregate several domain services into APIs for a
> > specific customer (e.g. there is a facade for our website, another for our
> > content management system)
> >
> > Facade APIs all RESTful HTTP, and they call the domain services over RPC.
> >
> > There's a fledgling example that shows this pattern here:
> > [GitHub - nameko/nameko-examples: Nameko microservices example](https://github.com/nameko/nameko-examples) (note the "gateway"/facade
> > service still in a PR).
> >
> > For auth, there are two approaches I've taken in the past:
> >
> > 1. Authenticate at the boundary (i.e. facade) and have domain services
> > just trust their callers (simple, but weak security)
> > 2. Also generate a JWT that contains permissions/roles for that identity,
> > and pass that along with every call so each downstream service can perform
> > its own authorization checks.
> >
> > We should try to add auth into the example app. The JWT approach sounds
> > complex but it's actually quite simple.
> >
> > I've already written about our ops/hosting in this thread
> > [Redirecting to Google Groups](https://groups.google.com/forum/#!topic/nameko-dev/Sfvm9xY6MHE)
> >
> > Hope that helps. I'd love to see some other folks adding their experiences
> > here too.
> >
> > On Monday, March 20, 2017 at 11:28:36 AM UTC, abhinav...@gmail.com wrote:
> >
> > > Hi All,
> > >
> > > We have a Django monolith and planning to move to microervices
> > > architecture. We came across Nameko and found it interesting.
> > > Is there list of projects using nameko in production or case studies/
> > > articles.
> > >
> > > It would be great if any of you can share your experience with Nameko.
> > > How you have architect it? How have you done authentication? etc.
> > >
> > > Thanks
> > > Abhi
---
### Author:  [@Fergus\_Doyle](https://discourse.nameko.io/u/Fergus_Doyle)
#### Post date: [April 3, 2017, 7:10pm UTC](https://discourse.nameko.io/t/who-is-using-on-production/178/5 "2017-04-03T19:10:51Z")
We use Nameko at Lystable to encapsulate our core business logic.
Our overall architecture is similar to the one Matt described with a few
sublte differences.
We use Flask applications/blueprints to provide the HTTP APIs our client
apps consume which constitutes the `Facade` pattern Matt described. This
stems from a decision made quite some time ago when the http support in
Nameko was still in it's relative infancy. That wouldn't necessarily be the
case if we were faced with the same decision today.
Our Facades / API Gateways are responsible for managing their own resource
definitions and corresponding data. What this means in practice is that
they rely less on direct RPC calls to formulate responses to HTTP requests
and instead maintain a local data store which is kept up to date by
serialising data from lifecycle (state change) events broadcast by the
domain services.
We also talk quite a lot about Domain services (in the context of Domain
Driven Design \<[http://domainlanguage.com/ddd/](http://domainlanguage.com/ddd/)\>). Services are considered
either Domain or Utility and each one has a clear remit or mission
statement to help enforce the service boundaries and mitigate the
likelihood of conflating services with logic outside of their
responsibility.
Domain services are responsible for (usually) a number of entities /
resource types, the related business logic and for publishing lifecycle /
domain events for any consequential state changes.
Utility services are used for breaking out more functional compute logic
that can be shared by other services. Examples here include sending email
notifications or centralised scheduling of timed triggers.
We also terminate authentication at the gateway and trust requests made
within the Nameko cluster.
The dependency injection patterns are really powerful and can help simplify
complexity significantly. It also means you're not limited to amqp or http
as transport protocols should you so desire.
Hope this helps.
Cheers,
Fergus
> **···**
>
> On 24 March 2017 at 03:18, \<[abhinav.sohani@gmail.com](mailto:abhinav.sohani@gmail.com)\> wrote:
>
> Hi Matt,
>
> Thanks for sharing the details. It has given me the fair idea.
> Looking forward to auth example.
>
> Thanks,
> Abhi
>
> On Monday, March 20, 2017 at 11:29:47 PM UTC+5:30, Matt Yule-Bennett wrote:
>
> Great question! Would love to see this thread grow.
>
> I can kick it off --
>
> We've been using Nameko in production at [Student.com](http://Student.com) \<[http://student.com/](http://student.com/)\> for
> ~2 years.
>
> In our setup we have:
>
> \* Domain services, which look after the data and logic related to specific
> domains in our business (we do student accommodation, so one service
> manages properties and rooms, another handles prices and availability, and
> so on)
> \* Facade services, which aggregate several domain services into APIs for a
> specific customer (e.g. there is a facade for our website, another for our
> content management system)
>
> Facade APIs all RESTful HTTP, and they call the domain services over RPC.
>
> There's a fledgling example that shows this pattern here:
> [https://github.com/nameko/nameko-examples](https://github.com/nameko/nameko-examples) (note the "gateway"/facade
> service still in a PR).
>
> For auth, there are two approaches I've taken in the past:
>
> 1. Authenticate at the boundary (i.e. facade) and have domain services just
> trust their callers (simple, but weak security)
> 2. Also generate a JWT that contains permissions/roles for that identity,
> and pass that along with every call so each downstream service can perform
> its own authorization checks.
>
> We should try to add auth into the example app. The JWT approach sounds
> complex but it's actually quite simple.
>
> I've already written about our ops/hosting in this thread
> [https://groups.google.com/forum/#!topic/nameko-dev/Sfvm9xY6MHE](https://groups.google.com/forum/#!topic/nameko-dev/Sfvm9xY6MHE)
>
> Hope that helps. I'd love to see some other folks adding their experiences
> here too.
>
> On Monday, March 20, 2017 at 11:28:36 AM UTC, [abhinav...@gmail.com](mailto:abhinav...@gmail.com) wrote:
>
> Hi All,
>
> We have a Django monolith and planning to move to microervices
> architecture. We came across Nameko and found it interesting.
> Is there list of projects using nameko in production or case studies/
> articles.
>
> It would be great if any of you can share your experience with Nameko. How
> you have architect it? How have you done authentication? etc.
>
> Thanks
> Abhi
>
> --
> You received this message because you are subscribed to the Google Groups
> "nameko-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [nameko-dev+unsubscribe@googlegroups.com](mailto:nameko-dev+unsubscribe@googlegroups.com).
> To post to this group, send email to [nameko-dev@googlegroups.com](mailto:nameko-dev@googlegroups.com).
> To view this discussion on the web, visit
> [https://groups.google.com/d/msgid/nameko-dev/0d89ea44-ea8b-4cf4-9c00-9a15c2887129%40googlegroups.com](https://groups.google.com/d/msgid/nameko-dev/0d89ea44-ea8b-4cf4-9c00-9a15c2887129%40googlegroups.com)
> \<[https://groups.google.com/d/msgid/nameko-dev/0d89ea44-ea8b-4cf4-9c00-9a15c2887129%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/nameko-dev/0d89ea44-ea8b-4cf4-9c00-9a15c2887129%40googlegroups.com?utm_medium=email&utm_source=footer)\>
> .
>
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).