Building Microservices the Lean Way, part 2 • Hacker News Board

Re: Building Microservices the Lean Way, part 2

#41

Post by mh- » Sat, Feb 28, 2015, 12:17 AM UTC

tekacs wrote: post #18

AndrewHampton wrote: post #14

So here's a question we've been talking about at my office. When developing a micro-service on your development machine, do you need to run the whole stack or just the service you're working on? For example, let's I am working on service A, which depends on services B and C. Do I need to run all 3 apps and their data stores locally? We currently will typically point A to the staging B and C. However, we have some lon…

One option is a framework[1] which tries to start dependent services locally. A stopgap solution is to use something like an Actor[2] model, which schedules actors on an ActorSystem and to clone the context/scheduler/system for each client ID. As long as your actors are fairly sane, this should be fairly lightweight. Then just shut down the actors for a given client (actorSystem.shutdown() under Akka), either after a…

just wanted to ask, in the footer on wym.io it mentions "wym-core is open source software".. but I wasn't able to find the source or a repo anywhere?

Re: Building Microservices the Lean Way, part 2

#42

Post by bbyars » Sat, Feb 28, 2015, 4:35 PM UTC

tekacs wrote: post #22

AndrewHampton wrote: post #21

Earlier quoted context omitted.

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 ta…

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.

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.

Re: Building Microservices the Lean Way, part 2

#43

Post by bbyars » Sat, Feb 28, 2015, 5:26 PM UTC

jasonwocky wrote: post #20

AndrewHampton wrote: post #14

So here's a question we've been talking about at my office. When developing a micro-service on your development machine, do you need to run the whole stack or just the service you're working on? For example, let's I am working on service A, which depends on services B and C. Do I need to run all 3 apps and their data stores locally? We currently will typically point A to the staging B and C. However, we have some lon…

Depends on the use case. For automated testing, if I'm developing service A, then locally I'd usually I'd want to stub B & C with something like Mountebank ( http://www.mbtest.org/ ) (though I've never used it to do a post-back as you describe...not sure if it supports that out of the box). If I just wanted to poke around a running system to see how things interact manually, yeah I'd run everything locally. Probably…

mountebank could support that through stub resolver injection (http://www.mbtest.org/docs/api/injection). Basically, in addition to returning a response, you can inject some javascript that would call back after some time. Tricky, but possible.

Re: Building Microservices the Lean Way, part 2

#44

Post by tekacs » Fri, Mar 06, 2015, 9:24 PM UTC

bbyars wrote: post #42

tekacs wrote: post #22

Earlier quoted context omitted.

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.

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.

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.