Microservices in CityU
In our previous issue (Ref: Network Computing Issue 97 – October 2018), we introduced the newly designed CityU Mobile v2, covering the enhanced UI design, the technologies used in the core, as well as new capabilities like checking room availability, retrieving library loan records, etc.
These new capabilities have to rely on multiple data sources from distributed systems both on-premise and the cloud. The traditional way to implement this is to have the mobile app itself connect with the different sources directly. But instead, the IT Services took this opportunity to introduce the microservices architecture [1] in our development lifecycle, decoupling the application from the data sources, and promoting future scalability, agility and reusability.
Monolithic and Microservices
Traditionally computer systems are developed using the Monolithic approach, i.e. the core of the system, the domain functions and corresponding data connections are all bundled together into a single package. It is simple and works great, though it lacks agility. When the system continues to grow, just a simple change in part of the system will still trigger an extremely time-consuming cycle in repackaging the whole application, going through all the test cases, as well as a large-scale deployment. It gradually becomes a bottleneck of the software development lifecycle and thus unable to cope with the ever-changing requirements.
To remedy the situation, the Service-Oriented Architecture (SOA) was brought into play. In a SOA, the system is divided based on domains, each of which exposes web services for the system core to consume. Hence, each web service could be tested and deployed independently, reducing spaghetti codes, enhancing the overall agility of the development and shortening the time to market.
The Microservices architecture can be considered as one of the SOA patterns that further divides the services into granular pieces, promoting reusability and allowing each piece to be highly scalable through the use of container technologies like Docker [2] when needed.
Let us take the library loan record retrieval as an example for illustration. For the SOA, there may only be one web service being exposed that takes in user's identification number and returns all the content. In contrast, the Microservices approach will further divide the web service into multiple granular services, e.g. one service that returns user profile, another service that retrieves loan records, and the third service that displays the media attributes. As a result, all three Microservices could be orchestrated together to achieve the same effect similar to the one in the SOA, while at the same time each of them could be consumed by other services or applications for different purposes.
Furthermore, in the Microservices architecture, RESTful APIs are being used as a common language between services and systems. This eliminates the need for establishing and maintaining an extra layer of Enterprise Service Bus (ESB) that is required by the SOA.
RESTful API Design
To achieve the decoupling style of the Microservices architecture, RESTful APIs are normally being used, which includes a resource as well as a corresponding resource representation, and it follows the 6 guiding principles of REST [3]. If HTTP is being used for the API implementation, that will be the URI and HTTP protocol respectively, and the HTTP status code could further indicate if the API execution is a success or not.
APIs should be well architectured in the early stage as not only will it affect their ease of use by API consumers, it also relates to future scalability and extensibility. Some general fashions one may follow are listed below, and there are other valuable resources available on the web [4] [5]. We may also reference other big brands when designing the APIs, like Google [6], Dropbox [7] or Instructure Canvas [8].
CityU API Platform
In August 2018, IT Services deployed a central API platform in parallel with the release of CityU Mobile v2. The API platform connects with and aggregates multiple data endpoints such as Oracle, MSSQL, Google API, DATA.GOV.HK, etc, exposing ready-to-use data in a centralised RESTful API gateway.
Apart from being a centralised gateway, the API platform also boosts up the speed of data consumption dramatically. With a memory-based caching policy in place, the time it takes for the portal to return data to the client can be less than 100ms, much faster than retrieving directly from the database that sometimes takes seconds.
CityU Mobile is the first consumer of the API platform as a proof of concept. The IT Services have been working on expanding the use of the API platform for other systems. We are looking forward to being able to release the API platform to departments or even students in the future, to flourish in future applications developed in CityU.
References
References
[1] DZone - Microservices Introduction (Monolithic vs. Microservice Architecture)
https://dzone.com/articles/microservices-1-introduction-monolithic-vs-microse
[2] RubyGarage - Advantages of Using Docker for Microservices
https://rubygarage.org/blog/advantages-of-using-docker-for-microservices
[3] RESTfulAPI.net - REST API Tutorial
https://restfulapi.net/
[4] Octo - How to design a REST API
https://blog.octo.com/en/design-a-rest-api/
[5] Hacker Noon - API Design The guidelines
https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9
[6] Google Developers - Google API Explorer
https://developers.google.com/apis-explorer/#p/
[7] Dropbox, Inc. - Dropbox API Explorer
https://dropbox.github.io/dropbox-api-v2-explorer/
[8] Instructure, Inc. - Canvas REST API Documentation
https://canvas.instructure.com/doc/api/