Developing Microservices? Points to Ponder. Part - 1

Developing Microservices?

Yes(either by you or in your organization), might be the answer from most of you reading this blog. As you could understand from this title I'm going to share my experience in developing microservices based architecture in series of posts each post concentrating on one particular area. As I have been building services for a while using Spring Boot do bare with the solutions that are concentrated in and around with the frameworks provided by Spring EcoSystem.

Why there is a buzz around Microservices? 

A collection of loosely coupled services (Fig-1 is simple deception of Microservices architecture) that structures an application. In a microservices architecture, services are fine-grained, the protocols are lightweight and modular making the application easier to understand, develop, test and resilient to architecture erosion. It also facilitates parallelizes development, deploy, scale services independently, refactor individual service architectures and finally facilitate continuous delivery and deployment. There art 'N' articles out in the web that gives the proof for the above points but, there are very few of them that gives us the points to ponder while developing Microservices.

Fig -1 Microservices architecture

The following are few areas (in no particular order) in which I would like to share my experience while developing applications in Microservices architecture because, I firmly believe when we have all the following in place it would really help us reap the real benefits of Microservices architecture.

• Configuration Management
• Logging
• API gateway
• Service Discovery
• Circuit Breaker
• Authentication
• Database Communication & Migration
• Inter Service Communication
• Integration testing
• Deployment 
• Monitoring

In this part - 1 of the blog, I'll be going through the evolution of the path in which we were handling the configuration management of services from monolithic ages to the current era.

Configuration Management

Software configuration management plays a significant role while developing any services. A small mistake with configuration dependency system might lead to potential business loss (can be in the form of monetary or reputation of the organization). I have seen or seeing the evolution of various approaches in handling configuration management and here is a glimpse of few approaches that are adopted in the projects in which I worked:

• Shell Scripts
• Environment Variables
• Environment Profiles
• Configuration Management tools (Puppet, Vagrant,....)
• Configuration Server (Spring Cloud Config Server, Consul,...)

Shell Scripts?

Yes, shell scripts for configuration management. Gone, are those days were operations team used to have shell scripts to update/modify the configuration files while deploying each and every builds in production environment. The problem with this approach are dangling configuration files, dangling shell scripts basically due to lack of synchronization between the dev and operations teams. I'm not getting much into the details of how the scripts looked in this blog or post.

Environment Variables

As the configuration related to application does not change from environment to environment few people thought to leverage Environment variables for the attributes that change quite often and it's up to the operations team to make sure the variables are exposed to the application at the time of deployments. Still, few issues were not solved due the synchronization issues.

Environment Profiles

As a work around developers started to ship configuration files for different environment along with the deliverables to avoid issues due to lack of synchronization. But, it exposed few credentials to the team who has access to code repository and making security endpoints closed with keys left in the lock.

Configuration Management Tools

Then with the arise of multiple configuration management tools like puppet, vagrant and similar tools, IT infrastructure management was made easy addressing cross cutting concerns like provisioning, patching, configuration, and management of operating system and application components. Though, these tools helped the community significantly in the era of virtual machines and did not got the significance in the era of micro-services. 

Configuration Servers

As the era of micro-services was picking up things have changed drastically with respect to the configuration management and we have started moving towards servers for persisting configurations with different profile. I have used the following two services to persist my configurations:

1. Spring Cloud Config Server
2. Hashicorp Consul
3. Hashicorp Vault

While the later has a numerous out of box features that can be used in micro-services architecture the adoption of it slightly higher that the former. Also, integrating Consul with micro-services is made easy through library.

Like Consul, Vault is also a distributed external configuration system with additional features to manage secrets and protects sensitive data. Few applications might have to maintain seed data confidentially when it's exposed in distributed configuration system it might be open so Hashicorp has built a Vault to cater the needs of applications that maintains data sensitive also, like Consul integrating Vault with spring applications would be a cake walk through the spring cloud vault.

Please, feel free to leave your comments and suggestions to improve my post. Also, let me know if you're looking for more details.