HN Explorer

Ask HN: Anyone out there using Developer Anarchy / Micro-services?

6 points by lifeisstillgood ↗ HN
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.

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).

I was interested if anyone else tries or uses micro-services - any feedback, good or bad.

5 comments

[ 16.4 ms ] story [ 700 ms ] thread
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