Cloud ready application Architecture must implement service discovery and externalized configuration as key design patterns in addition to other key design tenets such as isolation, security, idempotency etc.

A   cloud   ready   application   architecture must  follow  certain  design  principles  – few    of    them    being    loose    coupling between    application    components    and properties.   Whether   the   application   is built    using    RESTful    micro    services architecture  or  asynchronous  pub/sub  or another   design   pattern,   ultimately   the

application components must have the capability to discover each other and must be configured and orchestrated using common set of properties. This enforces the need of a service discovery mechanism  and  methodologies  to  decouple  the  application  properties  from  actual  application components.

2.    Abstract / Business Case

A  cloud  ready  application  should  not  have  any  infrastructure  dependency.  The  application developers should not assume that the components will run on particular hosts or even ports. The developers can orchestrate the order in which services will be called but they cannot assume the physical location of those services. This leads to the need of “service discovery” design pattern.

Service discovery is needed so that application components can discover each other. Also all the business components should get registered as services in a centralized manner for monitoring and control purpose.

Externalized configuration may store the information about how the services need to be orchestrated along with other common application properties. This information must be externalized to be able to dynamically update at runtime and not impact any deployed application components.

Similarly   the   component/service   orchestration   details   and   other   configurations   must   be abstracted  and  isolated  from  deployed  components.  Any  changes  to  application  configuration

should be propagated to only the impacted components and should be transparent to rest of the application components.

While there are several  out of box  solutions for service discovery namely Consul,  Zookeeper, and  Eureka  etc.  this  paper  focuses  on  achieving  these  design  principles  using  Zookeeper  and Spring Netflix Eureka.

For externalized configuration, this paper will focus on Zookeeper and Spring Cloud Config.

3.    Problem Statement

Some  of  the  key  tenets  of  cloud  ready  application  are  service  discovery  and  externalized configuration.  This  paper  does  not  aim  to  cover  all  the  design  principles  of  a  cloud  ready architecture but focuses only on service discovery and externalized configuration.

The paper describes case studies of how the author applied these design principles using some out of the box solutions namely Zookeeper and Eureka and Spring cloud config.

The  case  studies  referenced  below  refer  to  a  cloud  ready  application  consisting  of  individual components/services.   These   components   are   wired   using   message   broker   and   RESTful endpoints.  Service  discovery  deals  with  the  scenario  of  inter  application  communication. Externalized   configuration   deals   with   the   scenario   of   dynamic   update   to   application configuration in a single place without restarting the application components.

4.    Proposed Solution(s)

4.1.First Solution – Eureka/Spring cloud config

4.1.1. Introduction of Solution

The first solution described here uses:

  Spring Netflix Eureka for service discovery

  Ribbon for load balancing

  Spring cloud config to externalize the topology configuration

  Spring actuator endpoints for environment details

  Eureka dashboard to view all the deployed component instances and the status

Further elaboration on Ribbon and actuator is out of scope for this paper.

4.1.2. Application of Solution

The application configuration/properties are stored GIT repository and application accesses the properties  via  Spring  Cloud  config  server.  Multiple  instances  of  Eureka  server  run  in  load balanced  mode  for  resilience.  Application  components  register  themselves  as  services  with Eureka which is monitored at instance level using Eureka dashboard. Components use Ribbon load balancer to for intra application communication.

Application  configuration/properties  are  externalized  in  GIT  repository  so  that  they  can  be independently updated without the need for restarting the components.