Recently at Tangosource I was assigned to work on an internal project named Dev Jobs (see dev jobs on iOS and dev jobs on Android), where I had the chance to work next to great teammates and implement a microservice architecture with Ruby on Rails, nodeJS, JWT, Ionic, Docker, and several testing tools, including RSpec, Mocha, Frisby, and Protractor. In this first post, I’ll explain the basics of the microservice architecture.
What is a Microservice Architecture ?
Martin Fowler gives a great definition.
[1]“The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”
The Problem
Let’s have some context. We are building a server side application that must support different client side platforms such as:
- Desktop browsers
- Mobile browsers
- Native mobile applications
Also, we need to consume an external API service. In our case, Linkedin through Oauth2 for authentication. And the ability for users to chat between each other.
On an architectural matter we still had to decide between monolithic or microservice. So let’s dig a little more on this two.
Monolithic vs MicroServices
Monolithic
If we take this approach, we need to keep the following in mind:
- Build one application to rule them all.
- Use one language ( Ruby, PHP, JavaScript, etc. ) we could not take any extra advantages from other programming languages.
- The architecture needs to be flexible enough to support API through AJAX and render HTML.
- The development team needs to feel comfortable with the language we picked.
- Security. We will have a public API to serve mobiles/clients.
- Best tools for RTCP. So we can have a nice looking chat
- Testing. build testable code
I have seen great monolithic architectures that can support all of this. One of my favorites is RoR engines based or nodeJS services based applications.
MicroServices
In the other hand, if we go for MicroServices we must take in mind the following:
- Delegate responsibilities in small applications.
- We can use different languages per service. Which is the best choice per responsibility?
- How are we going to communicate each service ? Normally with tcp/ssl.
- How are we going to persist Data through services?
- Security: Protect the services.
- Testing: Test all microservices.
On a personal note, as a developer working on a microservice platform, I can focus only on the technical details wrapping a specific service. This does not mean I should not understand the whole set of services as a unit.
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
— Melvyn Conway, 1967
Having this in mind, we had to start by making technical decisions, such as how to protect our API, how to manage RTCP, by nature HTTP is stateless which means is sessionless so for our case we had to maintain a session through tokens ( JWT ), at first we though maybe nodeJS for RTCP since nodeJS is strong for DIRT ( Data Intensive Real Time ) apps. But we had not only had to take care of the tech devs but also for dev resources, currently at TangoSource we have strong Ruby on Rails devs so we had to work all together and take advantage of the expertise of each team member, our best bet was to use RoR for business logic, and take advantage of nodeJS. So the combination of RoR and nodeJS makes the solution solid and strong.
Solution
For this particular project, we decided to go for the MicroService and have some fun! The first thing that we needed to figure out was defining the responsibilities per service. So we end up with 4 microservices.
- Ionic
- More than a service, it’s the client side of the application. Ionic by itself is a front end SDK for hybrid mobile apps using AngularJS.
- IDP
- Responsible for (a) providing identifiers for users looking to interact with a system, (b) asserting to such a system that such an identifier presented by a user is known to the provider (c) possibly providing other information about the user that is known to the provider.
- This may be achieved via an authentication module, which verifies a security token, and that can be accepted as an alternative to repeatedly and explicitly authenticating a user within a security area.
- SP
- In charge of persisting all user’s data, including interaction with the system. This service will contain all the business logic
- Chat
- In charge of establishing real-time communication among users within the system.
We decided to protect the services with JWT
Architecture
Each square represents a service, and the lines are how they communicate between each other.
Ionic : This might be the most critical service of them all, but not the most important. We have 3 main components:
- Ionic server
- An HTTP server in charge of sending all the assets ( HTML, CSS, JS ) to the next component.
- Ionic Cordova
- A Mobile SDK, which provides the user’s interaction with the app, and consumes the rest of the microservices as resources. This component runs on top of 3 different type of devices.
- Android
- Ios
- Browser
- A Mobile SDK, which provides the user’s interaction with the app, and consumes the rest of the microservices as resources. This component runs on top of 3 different type of devices.
- Ionic App
IDP : This service is in charge of giving identity to a component/user. This service will expire a valid token with a component/user’s basic information on the JWT’s payload. Similar to memoization, this service will keep track of sessions using Redis on a basic TLS connection. Thanks to the RFC 7519 standard, this service can scale in other microservice based architectures and be reused.
SP : This is an API/Https service protected with JWT. This micro service is in charge of persisting all user’s interaction/information using MySQL with a standard TLS connection. It also manages the business logic.
Chat : This microservice will provide real-time communication between users. This RTCP (real time control protocol) is being protected with JWT on the handshake process, and persists the communication activity on MongoDB, a NoSQL database.
Conclusion
Taking these kind of decisions is not simple. It requires a lot of experience in order to compare libraries/languages, you must at least know how they work, and it’s even better if you have used them. Remember that you will not build this by yourself, you are part of a team. It’s smart to sit with your team and discuss each individual’s strengths and weaknesses in order to make the best tech decisions.
DO NOT mix responsibilities of the micro services, instead identify your services. Add all the needed documentation to help the team such as /*Comments */, READMEs, and Wikis.
A microservice architecture is not always the best approach, and could be painful if you are not careful.
