34

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.

Maciej Treder
  • 11,866
  • 5
  • 51
  • 74
  • It seems you have a few things mixed up (Heroku and Gitlab are different types of company, one hosts your webapp and the other hosts your code/CI). Also, if you aren't sure what JHipster is, I would recommend reading up on the docs before you dive into generating microservices with it. Here's an article covering deploying JHipster microservices on Heroku: https://blog.heroku.com/bootstrapping_your_microservices_architecture_with_jhipster_and_spring – Jon Ruddell Jan 23 '17 at 00:34

1 Answers1

60

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.

Carl Manaster
  • 39,912
  • 17
  • 102
  • 155
rdegges
  • 32,786
  • 20
  • 85
  • 109
  • Big thanks for your answer. Could you expand it and tell me what You think about using data docker images on heroku? If it is not common (because Heroku provide nice scaling mechanisms) why there is so much informations and articles about that around the Internet? Also I would be really happy if I could know your mind about Netflix solutions like Eureka or Zuul. I guess that Eureka is common as an entry point for my services, but as far as I understand load balancer is overhead, am I right? – Maciej Treder Jan 23 '17 at 18:28
  • 3
    Hey, I think these are best suited for other StackOverflow questions. It will confuse readers if I put all that in this thread. – rdegges Jan 23 '17 at 18:55
  • 1
    You're right. I have added new question http://stackoverflow.com/q/41814001/2849613 . Take a look if You would like to ;) – Maciej Treder Jan 23 '17 at 19:24
  • 1
    @rdegges BTW according to Terms of Service 4.4 https://www.heroku.com/policy/tos it seems microservice applications might not be allowed as they basically `imulate or act as a single Application`. Or am I wrong? – lapots Nov 15 '17 at 13:29
  • 2
    This is no longer relevant. Heroku doesn't provide 1 free dyno to each app you have. They changed their pricing model a while ago. You now get a set amount of free dyno hours per month, that are used across ALL apps. So this won't make a difference. – rdegges Nov 16 '17 at 18:41