
Ask HN: Anyone out there using Developer Anarchy / Micro-services? - lifeisstillgood
So Fred George has an idea called Developer Anarchy, which sounds strange but is really just assuming that everyone in a company will be able to code.<p>And they have tried it out at uswitch dot com - IIRC everyone who runs it is a developer, and one of their prime tools is tiny web services doing one thing (well).<p>I was interested if anyone else tries or uses micro-services - any feedback, good or bad.
======
lifeisstillgood
Some links that might interest people

[http://yobriefca.se/blog/2013/04/29/micro-service-
architectu...](http://yobriefca.se/blog/2013/04/29/micro-service-
architecture/)

[http://martinfowler.com/articles/microservices.html](http://martinfowler.com/articles/microservices.html)

------
tomasztomczyk
I don't think Developer Anarchy is tied to idea of micro services? We empower
developers to write code and deploy it to production daily to avoid any
bottlenecks to do with management; we write microservices where it makes sense
to decouple systems and make them into reusable services.

(I work at uSwitch)

~~~
lifeisstillgood
yes, sorry, I did conflate the two, mostly because I can't write for toffee. I
am I guess mostly interested in what you guys (or indeed anyone else)
considered microservices, and how you manage them - announcing presence,
handling messaging, etc.

But the (not linked) idea of Developer Anarchy is also attractive - how is it
working for you guys? Is the organisation actually just developers?

Really just trying to get a handle on something I am doing / trying and want
to know how others are doing.

~~~
tomasztomczyk
Microservices here are mostly fancy word for an API or an app consuming API or
listening for events. At least in my department, we have a fair amount of
legacy code, coupled together, as the application and CMS grew over the years;
we're now working on splitting things up, e.g. reports don't need to be part
of the same code as CMS. Scheduled jobs for grabbing 3rd party feeds can be
separated into its own app. Any significant part of the system is eventually
going to be living on its own - so that deploying one part shouldn't break
others; running a bad query on our reporting DB will not affect production DB
etc.

I guess the downside of this approach is having to manage overhead of each of
these services (setting up puppet, nginx, caching etc.); majority of our apps
live in a shared puppet config so it's not too difficult to spin up a new box
in EC2 and apply puppet to it, but also as you grow bigger you might want to
split out these configurations (different teams = different needs) or have a
curated/moderated central configuration (that's sort of the way we have it
now).

Regarding communication between services, not sure exactly what you mean,
usually when we split something out of existing system, the legacy code just
makes a call to this new external service to get the data.

Regarding Developer Anarchy.. no of course we're not just developers :) Each
dev team works with designers, marketing and commercial people.
Priorities/objectives come from business people and we just help them figure
out how to reach their goals and inform them on possibilities from technical
side. Day to day however, we're mostly left to our own, so it's pretty great.
We don't have project managers in a typical sense, we decide our timelines and
tools. I haven't seen that video yet, it's also before my time here (I've been
here 1.5 year), but either way it's very developer friendly environment with
plenty of freedom.

Ping me on Skype (tomasz-tomczyk) or email if you'd like to know anything
more.

~~~
lifeisstillgood
> Regarding communication between services, not sure exactly what you mean,

I am mostly thinking message queues like 0MQ or rabbit

Thank you - I will drop you a skype connect thing

