Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building Microservices the Lean Way, part 2

blog.hubblehq.com

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Building Microservices the Lean Way, part 2

#31

Post by DanielBMarkham »

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…

Wouldn't blue-green deployment and immutable servers make this a non-issue? Or to put it differently, you probably shouldn't have a staging environment.

Re: Building Microservices the Lean Way, part 2

#32

Post by akbar501 »

Questions for Tom:

1.) How are you handling auth? Are you using a home grown solution or using OpenID Connect + OAuth 2.0?

2.) Is the JWT behind the firewall using a pre-shared key?

3.) What does the public token look like and how does the API Gateway perform auth? Does the token passed into the API Gateway contain only a user id? And does the API Gateway have to perform a database query to populate the full user object?

side note: Thanks for writing the article.

Re: Building Microservices the Lean Way, part 2

#33

Post by graffitici »

lobster_johnson wrote: post #23
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…

Can't speak for the author, but I can tell you what we do in our company, which is also completely microservice-based. Backstory: We used to have a helper tool that allowed a developer to run any app locally. It tried to set up the same stack as we were using in production: HAproxy, Nginx, Ruby, Node, PostgreSQL. It was problematic, because people had machines that differed slightly: Different versions of OS X (or Li…

I always am amazed at these comments. This in itself contains as much info as the OP! I feel like they are getting lost in HN. Copy-paste to medium? :)

Thanks!

Re: Building Microservices the Lean Way, part 2

#34

Post by wtbob »

adaml_623 wrote: post #26
gabrtv wrote: post #25

> The services are considered to be in a trusted network and are accessed by a private token passed in the ‘Authorization' header plus the user id of the requester in an ‘X-USER’ header. This reads like the user ID is exposed in a header without any sort of encryption.

What does 'trusted network' mean to you? A lean quick service is not going to want to wait on encryption handshaking.

On modern hardware, I believe AES and SHA-384 are very cheap. But yes, in a private network it's overhead.

Re: Building Microservices the Lean Way, part 2

#35

Post by rgarcia »

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…

You should check out a tool we built to solve this problem at Clever: https://github.com/clever/aviator

It lets us spin up a service + all dependent services locally with a single command.

Re: Building Microservices the Lean Way, part 2

#37

Post by danesparza »

rgarcia wrote: post #35
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…

You should check out a tool we built to solve this problem at Clever: https://github.com/clever/aviator It lets us spin up a service + all dependent services locally with a single command.

It's my understanding microservices shouldn't have many dependencies on one another. The link to you blog post that explains your rationale doesn't appear to work... do you mind explaining what need this fills?

Re: Building Microservices the Lean Way, part 2

#38

Post by curun1r »

lobster_johnson wrote: post #23
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…

Can't speak for the author, but I can tell you what we do in our company, which is also completely microservice-based. Backstory: We used to have a helper tool that allowed a developer to run any app locally. It tried to set up the same stack as we were using in production: HAproxy, Nginx, Ruby, Node, PostgreSQL. It was problematic, because people had machines that differed slightly: Different versions of OS X (or Li…

We do roughly the same thing, but with Docker and Fig. We're already using Docker to package our services for deployment, so using Fig to spin up a full environment is pretty painless. And Fig also makes it simple to spin up environments for running integration tests as part of CI to ensure that the Docker containers being deployed and used by developers are always in a working state.

Re: Building Microservices the Lean Way, part 2

#39

Post by jeddf »

lobster_johnson wrote: post #23
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…

Can't speak for the author, but I can tell you what we do in our company, which is also completely microservice-based. Backstory: We used to have a helper tool that allowed a developer to run any app locally. It tried to set up the same stack as we were using in production: HAproxy, Nginx, Ruby, Node, PostgreSQL. It was problematic, because people had machines that differed slightly: Different versions of OS X (or Li…

Bookmarked this, thanks for taking the time to write it up.

Re: Building Microservices the Lean Way, part 2

#40

Post by lobster_johnson »

curun1r wrote: post #38
lobster_johnson wrote: post #23

Earlier quoted context omitted.

Can't speak for the author, but I can tell you what we do in our company, which is also completely microservice-based. Backstory: We used to have a helper tool that allowed a developer to run any app locally. It tried to set up the same stack as we were using in production: HAproxy, Nginx, Ruby, Node, PostgreSQL. It was problematic, because people had machines that differed slightly: Different versions of OS X (or Li…

We do roughly the same thing, but with Docker and Fig. We're already using Docker to package our services for deployment, so using Fig to spin up a full environment is pretty painless. And Fig also makes it simple to spin up environments for running integration tests as part of CI to ensure that the Docker containers being deployed and used by developers are always in a working state.

We are indeed planning to migrate to a Docker-based deployment system. I have looked briefly at Docker Compose (new name of Fig), and also at somewhat bigger orchestration systems like Kubernetes.

One goal is to get rid of Puppet (which is, frankly, a buggy, badly-designed mess) and move to a more dynamic, fluid orchestration system based on discovery and autoscaling.

Post reply on HN