We see a lot of people trying to deploy JHipster applications on Clever Cloud. It does not seem to be fully understood all the time. Especially with the differences between deploying on IaaS and PaaS. And since JHipsterConf is around the corner, it's the perfect time to write about it, to explain a bit what it is and how it can be deployed on PaaS platform like Clever Cloud.

What is JHipster?

If you are not familiar with JHipster, it's a scaffolding system to bootstrap applications using Spring Boot and AngularJS or React. You can choose to scaffold a monolithic application (Which are great and modular and everything because Spring Boot lets you build modular monolith. If you have no idea what you are doing you should start with this) or microservices architecture with an API Gateways and a registry.

When scaffolding microservices, you are using the Spring Boot and Netflix OSS stack. That’s something you want to know in general when looking for documentation online. Most of the things you will read here apply both to JHipster and to Spring Boot + Netflix OSS deployments.

JHipster or NetflixOSS versus IaaS or PaaS

Is there an incompatibility between JHipster/Netflix OSS and PaaS deployment? The reason I am raising this question is that this stack was pretty much made for IaaS deployment, more particularly AWS, where fewer things are managed than on any PaaS platform.

And as such JHipster comes up with lots of nifty tools to compensate the absence of services usually provided by higher level solutions like CaaS or PaaS. This is especially true when you are deploying a microservices architecture. So, will this overlap when deploying on Clever Cloud? Are things even compatible? Yes, it is, and in this post, I will show you some exciting things you can do.

Reverse proxy and Service Registry

One of the central question raised by our users doing microservices is how do you configure the JHipster Registry (Eureka in Netflix OSS terms). It maintains a registry of all the instances of your architecture services.

Going back to a classic AWS deployment, the typical behavior when you manage several instances of the same application is to deploy those apps to VMs. They all have their own set of IP/port. In their configuration, they have the different addresses of their Eureka server. They will register to that server as an instance of a particular application, identified by that IP/port couple. It is great when you manage your private network and plan to expose everything through an API gateway or your reverse proxy.

But as it turns out, this is already managed by PaaS providers like Clever Cloud or Heroku. So you don't have access to that IP/port for each instance. But it's OK. Eureka can be configured to support setup like these. You can use the URL given by the proxy instead.

The only issue with that is that you won’t be able to go on one specific instance since you go through the proxy. In some cases, this can become a problem. Like with the JHipster Registry.

JHipster Registry’s Statefulness Exception

Let’s say you want to scale out your registry for failover. It seems like a legitimate thing to do. If you only have one JHipster registry instance and it’s down, you lose your service registry(Eureka) and your configuration server (Spring Cloud config, embedded in the JHipster registry, more on that later). It means your architecture is down. So you want to have several instances of the registry in case one goes down.

Something also worth to know is that the service registry(Eureka in Netflix OSS terms) stores things in memory. You cannot store the information in a shared database that all your instances could use. It makes the registry stateful. They all have their datastore(their RAM). So you need to have your services register themselves to each registry instance to make sure they always have the same copy of the data.

If you were to use the URL of your JHipster registry application given by a PaaS, so behind a reverse proxy, the service would register to a random. It depends on the PaaS load balancer. In that case, you have no guarantee that your service will have registered itself with every instance of the registry.

If you use an IaaS, you will have all the IP/PORT couples at your disposal to make sure each service can register to each registry.

If you use PaaS autoscaling, each instance is hidden behind a reverse proxy with only one URL, and you have no way to have the clients register themselves to each instance (Now you could use sticky sessions, but you would have to craft the sticky session cookie manually, and this is cumbersome). So it is much simpler to create one application with its URL instead.

In that case, what you need to do is deploy an application for each instance you would like. That way you get a different URL for each, and you ask all your services to register to each URL.

Configuration Management

Another feature that comes up with most Platform as a Service and overlap with JHipster or the Netflix OSS stack is configuration management. In JHipster case, the registry is also a Spring Cloud Config server. As such it supports different backends to store your configuration: Git, native filesystem, Databases or Vault. By default JHipster uses git. Using GitHub, in particular, is excellent as you can benefit from their WebHooks. Each time you change the configuration, your server will receive the updates and broadcast it through an AMQP system with Spring Cloud Bus if you have configured one. So, you are sure that all your architecture is up to date with the latest configuration.

And of course, Spring Cloud Config also supports environment variables which is what we offer by default with Clever Cloud, with some exciting orchestration tricks.

The PaaS granularity level being Application(as oppose to VMs in IaaS), you can assign environment variables to Applications. All these variables are injected into all the instances of the app when we boot the VM. Applications can also expose some variables for others. How does it work?

Applications or add-ons can be linked together. It merely means that their exposed variables will be injected into the linked app. And the great thing about this is that when an exposed variable is modified, all the linked apps are restarted in blue/green so without service interruption. So you get an up to date architecture without having to setup Webhooks and an AMQP with Spring Cloud Bus :) Note that Clever Cloud also offers a configuration provider addon that lets you define configuration without having to tied it to an app. It is a bit like a configuration server. And it works exactly like described above. It's mostly here to make a semantic distinction.

Conclusion

JHipster and the Netflix OSS do provide some overlap to what PaaS can offer. But fear not because it’s still compatible and can benefit from the high-level feature supplied by PaaS. In the next post, I will show you all the steps to deploy this on Clever Cloud :)

At Clever Cloud, we've started using microservices before it was cool™. Today we're excited to launch service dependencies, to simplify microservices management.

The microservices graph

When you ditch your monolith and go full microservices, your application becomes a graph of loosely coupled microservices.

For instance, an typical service API can depend on:

• an auth microservice to validate requests
• a notification gateway to send notification

In turn, the notification gateway can depend on:

• an email gateway
• a push notification gateway

So you have a graph of services, each with its own lifecycle (eg dev, staging, production). So if you want to use a different email gateway from your staging API, you need to have in turn a specific notification gateway. To make a test in one project, you need to modifiy code in all its dependency chain. Uncool

Service dependencies

On Clever Cloud, you already know how to link applications to their dependencies on the fly, without touching code or fidling with config files: by linking an addon to your application, you let the addon inject its location and credentials so you don't have to handle it yourself. Service dependencies is just a generalization of the addon mechanism to any application.

Link applications

You can add dependencies to an application either from the CLI:

  clever service --alias api link-app notification-gateway

or from the console:

Exposed configuration

With addons, the exposed configuration is always the same. With applications, you can declare the configuration you want to expose to your dependents. To make an app expose configuration, you can either do it from the CLI:

  clever exposed-config --alias api set API_DOMAIN_NAME api.example.com

or from the console:

Note: every time you update the exposed configuration, dependent applications will be automatically redeployed.

If you’re used to code micro-services with Node.js, you may be familiar with the frustration of performance issues, finding the root cause of an error and hunting down memory leaks.

That’s why services like Trace are here. Trace is a Node.js performance monitoring tool which helps you to understand how your application behaves and lets you find performance bottlenecks with ease.

Today we are launching Trace as an add-on for Clever Cloud, which can be tried out for free until July 1st without any restrictions.

Distributed tracing

Trace comes with a unique feature called distributed tracing: It visualizes whole transactions (request-chains) in your microservices architecture and looks for errors.

This means that you can see on an interactive timeline:

• which services were taking part in a transaction,
• how big were the response network delays,
• how long did a service handled a request,
• where and when the errors happened in that transaction.

Trace connects services taking part in a request by attaching correlation IDs to them. This way you can visualize the exact data-flow of faulty transactions, see the dependencies between your microservices, look for bad status codes and localize ongoing issues.

Service mapping

Trace provides you with a dynamic service map, which is automatically generated based on how the services in your system communicate with each other, or with your databases and external APIs.

Thanks to this, you can see how your application really looks like, and understand what makes it to slow down. The service map also allows you to find out how many requests your services handle and how big are their response times.

Getting started

Adding Trace to your services is possible with just a couple lines of code, and it can be installed and used in under two minutes. There is a tutorial for the installation on Trace’s documentation: http://trace-docs.risingstack.com/docs/fix-crashing-nodejs-applications-with-trace

Some Use cases

Using Trace to fix crashing Node.js apps: http://trace-docs.risingstack.com/docs/fix-crashing-nodejs-applications-with-trace

Using Trace to investigate slow Node.js apps: http://trace-docs.risingstack.com/docs/fix-crashing-nodejs-applications-with-trace