How to deploy microservices on Heroku

Maciej Treder picture Maciej Treder · Jan 22, 2017 · Viewed 9.7k times · Source

I have read a lot about microservices, and would like to build my app with that approach. What I know so far is that I nead some services like:

  • load balancer - to deal with every request, and push it forward to another services
  • authorization service - to authorize my users
  • database - for my microservices. I would like to use one instance of DB with different schemas for every service.
  • service A - for functionality A
  • service B - for functionality B

  • etc. etc. etc.

I found out, that Heroku is interesting place to deploy applications. My problem is that I completely don't understand they ideology. What I have done so far, is creation/registration of few "apps":

  • my-app-auth
  • my-app-load-balancer
  • etc. etc.

I see, that Heroku gives me some public hostname for every of that app, and this is where my concerns starts. Should I deploy my internal services with public hostnames? I don't think so. And here my question comes:

Can anyone provide me some guidelines, how to deal with microservices on Heroku? How should i deploy them? How should I define my load balancer, and hook internal services to it? What is JHipster? Do I need it? How can I use it? Should I use Heroku tools (for example CLI) or can I stay with my gitlab repo? I can't find any point of grasp on the Internet, about that.

Answer

rdegges picture rdegges · Jan 23, 2017

Heroku is a very simple Platform-as-a-Service company. The way Heroku works is very straightforward:

  • You have multiple projects (services) in Git repos.
  • You create a Heroku app for each project (each Git repo).
  • You then push your code from each Git repo to their respective Heroku app.
  • Heroku assigns you a public URL for each app you have.
  • If each of your services is now running on Heroku, they can send API requests to each other over public HTTPs.

Now -- regarding your question about service oriented architecture on Heroku.

If you're doing SOA on Heroku, you'll need to have each service talk publicly with each other over HTTPS. This is the typical 'pattern'.

Because Heroku provides free SSL for each application, and each application is on the same Amazon region -- talking back-and-fourth between your services over HTTPs is very fast + secure.

Each Heroku app has automatic load balancing, so no need to worry about load balancers.

The next option here (if you don't want to follow the typical patterns) is to use something like RabbitMQ or Amazon SQS (a queueing service), and share 'messages' between your different services.

In this pattern, you would still have one Heroku app for each service, but instead of communicating with each other over HTTPs, you would instead communicate with your other services through a queueing protocol like Rabbit or SQS. This has some speed benefits.

In regards to authentication services, there are several providers you can use to provide this functionality. The most popular one I know of is Stormpath. If you look through the Heroku addon marketplace, you can find others as well.

Finally, for database stuff: you can use any Database provider you want. The most popular one is likely Heroku Postgres. It's a hosted version of PostgreSQL that's very reliable / easy to use.

You can either share one database amongst ALL your services, or you can have one databases per service. Either strategy will work fine.