Building Microservices the Lean Way, part 2

Re:Building Microservices the Lean Way, part 2 by AndrewHampton on Friday February 27, 2015 @09:04AM (#9118842)

Yeah, this is pretty much what we do. We only use test suites for the backend apps which only expose an API. They just stub out calls to other services.

However, our front end apps is where we're running into trouble. The people on the front end want to run through everything in their browser to make sure everything works and looks good.

We use docker and fig (now docker-compose) to run all our apps. So we've been talking about using compose's new external_links feature to link each app together.

I hadn't heard of moutebank though, so thanks for the link!

[ Parent | on HN ]

Re:Building Microservices the Lean Way, part 2 by tekacs on Friday February 27, 2015 @09:09AM (#9118860)

Mountebank/mocking is a great solution when your components are too big to spin up new ones for 'free'.

It's exactly because Docker-based components end up so big that it seems hard to believe in the viability of that approach to microservices though. :/

It's a great stopgap/migratory step, though.

[ Parent | on HN ]

Re:Building Microservices the Lean Way, part 2 by bbyars on Saturday February 28, 2015 @11:35AM (#9124126)

I think some level of integration testing is always a good thing, but spinning up all dependent services just so you can test yours leads to all kinds of problems, even in microservices. You end up with cascading dependencies.

At scale, some level of stubbing is required to test.

[ Parent | on HN ]

Re:Building Microservices the Lean Way, part 2 by tekacs on Friday March 06, 2015 @04:24PM (#9159652)

Agreed.

We _partially_ solve this problem by letting you run a dev cluster that you can use for services which are awkward to run locally, but stubbing/mocking definitely has a place in automated testing, certainly.

[ Parent | on HN ]