Migrating to Microservices and Cloud Native

“Microservices” is yet another buzzword in the modern application development scene. I always heard and read about it but had never actually implemented a non-trivial production system using Microservices architecture.

Last week, I attended a 2-day workshop titled “Migrating a Monolith Application to Cloud Native” conducted by Pivotal.

Migrating a Monolith Application to Cloud Native

You might have noticed that “Microservices” is never mentioned in the workshop title. I believe that is Pivotal’s branding strategy to push for their “Cloud Native” offering - “Spring Boot” + “Cloud Foundry”.

Nevertheless, the cool thing is the materials of the entire workshop can be found on GitHub at the following link.


This page consists of links to all the slides and hands-on lab exercises.

The following summarises some of my interesting learning points.

Spring Boot

Spring Boot is Pivotal’s attempt to simplify Java app development by favoring convention over configuration. This is achieved mostly by adding a few Maven dependencies and annotating Java classes. If I had to develop a Java web app, I would consider Spring Boot. However, I still feel more comfortable with Ruby on Rails.

Cloud Foundry

Cloud Foundry is Pivotal’s Platform-as-a-Service (PaaS), akin to Heroku, Amazon Elastic Beanstalk and Red Hat Openshift. We operate on Cloud Foundry using Pivotal Web Console as well as the command line interface tool. In particular, the command line tool makes application deployment as easy as running cf push from the terminal. Furthermore, Cloud Foundry’s Marketplace offers a wide range of services such as MySQL, MongoDB, Memcached, Message Queues, Redis, etc.

Shift in Paradigm

In the past, developers needed to make decision on the underlying hardware, virtualization platform and operating systems. Recently, container technology such as Docker has become prevailing but still does not solve the problem of managing large number of containers. PaaS addresses this pain point by allowing developers to focus on only Application and Data and forget about the underlying infrastructure.

What is Microservices?

My understanding of microservices is an architectural style where the system is composed of a suite of small independent and autonomous services.

Microservices vs SOA

Microservices is similar to Service Oriented Architecture (SOA) except that:-

  1. Enterprise Service Bus (ESB) is not used
  2. Communication pipeline is lightweight and dumb, eg. REST and AMQP

How to split a Monolith into Microservices?

  1. Based on domain classes and data relationship (boundary)
  2. Based on persistence storage (RDBMS vs Graph Database)
  3. Based on business value

Standalone Server vs Embedded Server

In the past, developers tended to deploy multiple application WAR/EAR into a server, eg. Tomcat, WebLogic, WebSphere, JBoss, etc.

With microservices, it is usually the other way round where each application will launch its own embedded server, eg. Embedded Tomcat, Jetty, etc. The benefit is each application server is independent of others.

Configuration Server

Spring Boot allows application configurations:-

  1. to be externalised by using application.yml or application.properties and Spring profiles
  2. to be overridden by environment variables if available

This approach is taken a step further by centralising configuration for all microservices in a single Git repository.

A Configuration Server is used for:-

  1. pulling configuration data from the Git repository
  2. serving configuration data to the respective microservices

Service Registry

All microservices have to register as “Producer” or “Consumer” with the Service Registry. This allows microservices to discover and talk to each other using the service name provided by the Service Registry, instead of hardcoding the microservices URLs.

Pivotal recommends building service registry with Netflix’s open source “Eureka”. Pivotal also recommends building consumer with Netflix’s open source “Feign”.

Client-side Load Balancing

I have to admit that this is a very new concept for me. Traditionally, load balancing is done in the server-side. Instead, microservices use client-side load balancing to decide which particular producer service to call. This allows consumers to intelligently select the best producer based on certain metrics such as network latency. The tradeoff is we cannot ensure that the service call load is evenly distributed among the producer microservices.

Pivotal recommends implementing client-side load balancing with Netflix’s open source “Ribbon”.

Circuit Breaker

The idea is a consumer calls a circuit breaker which checks the endpoint and responds to the consumer with whether the service call can be made successfully. If the service call fails for some reasons, the consumer simply proceeds with the error handling instead of calling the endpoint again and again subsequently.

Pivotal recommends implementing circuit breaker with Netflix’s open source “Hystrix”, which also comes with a nifty monitoring dashboard module.

To be Continued

Microservices is undoubtedly the trend for scalable architecture.

There are still a few questions unanswered:-

  1. When is microservices not recommended?
  2. How to effectively split the development team and system into microservices?
  3. How to secure microservices?
  4. How to automate integration testing for microservices?
  5. How to set up monitoring and alerts for microservices?
  6. How to implement microservices and cloud native on premise in a secure and restrictive environment?
  7. … etc.