chrisvxd

That's awesome! Thanks for sharing.

The tools are bespoke, and right now I don't plan on open sourcing them. I can't say what the future holds though, so watch this space.

Yeaaah.. me too... but MVP!

Afraid I can't at this stage

What he said... nvd3 and d3

Confusion is negative, so actually we're very sure of ourselves ;)

It really depends on the size of your micro services. If the services are small, then running each one (via some master shell script) shouldn't be an issue. If the services are large, then something like Vagrant would enable you to get a near-live environment fired up quickly and easily.

There is absolutely no need to use different languages and technologies within a microservices architecture if it is not necessary for your business. But to simply dismiss the business perspective from your perspective seems a little naive.

Some reasons why decoupling your architecture can make sense from a business perspective:

- You have a complicated product, and wish to break it up into more digestible chunks, with allocated teams working on each abstract business concept (Amazon and Spotify do this).

- You want to avoid having a single point of failure- if one service fails, the rest of the system might well keep on working. (Ever noticed how sometimes a panel on Amazon doesn't load?). If you're running a continuous development process, stuff breaks, a lot. It's good if that's locked down.

- You have a business requirement to build something with a different technology (from experience- rendering javascript in a node service was much, much easier and more maintainable than with an existing Django app- we tried both.)

- You want to experiment with new technologies without changing your whole stack.

I'm pretty sure that the author wasn't talking about moving to microservices so they can blindly start building every aspect of the application in a different stack- but more that if they need to use a new technology for their business requirements, or want to give something a trial without committing, they can. And with the uncertainty and rate things change in modern software, and in a startup, that flexibility is invaluable.

Adopting a microservice architecture does nothing to define how you "render your output"- the devil is still in the details, but that is why a microservice is so interesting and flexible.

The way you will tackle this will largely depend on many questions like what services are safe to be exposed publicly, what services are dependant on other services, do you have a public API?

For example, you could have a public facing API on each service, or endpoints that render HTML templates. The services may or may not talk amongst themselves, either via the same public API, or a private one. If you make a request to one of the services, and that service needs to make a request to another service to generate the response, you've got to make a call on whether you want a blocking or non-blocking approach. Consider:

1) Blocking until the other services have responded

2) Pinging the server to check when it's done

3) Using web sockets

4) Whatever the hell else you can think of

Alternatively, you might want not want to expose your services publicly, and choose to have a single service that talks to the services on the clients behalf, a middleman. Your client speaks to this service, and the service sends of various requests to the other services. But the problem still stands. To block, or not to block?

AFAIK some big names like Amazon, Spotify, (Twitter?) have multiple public services. You may sometimes notice individual components on their [web] applications failing without bringing down the whole site, since the failures are isolated to the different services. Neat, huh?