What I have learned from building microservices
Continuous Integration + Continuous Deployment.
Repeat with me: there is no agile without CI+CD.
Continuous deployments get you to the next level: iterations are shorter, your code is earlier in production, risk is lower. You will bold enough to push code to production on Fridays!
A common framework to build them eases the development
I know that microservices theorists encourage no coupling at all among services, either by data or by code. But a good base library and a good base Dockerfile for those services written in the same language will accelerate the deployment of new services.
Playtomic’s base library contains our typical configuration for Spring applications: security (including configuration and interceptors to call among services), converters, … and some very basic domain classes (such as users in the security context, location, addresses, …). More specific domain classes (such as players, venues, …) are not shared.
Eases the iteration and the update of libraries
Besides, if you release these base components in an ordered way, with a decent versioning, it eases the upgrading of dependencies of your services. For instance, we started with services in Spring Boot 1.x and Java 1.8. We experiment and upgrade libraries in the new services. Older microservices get upgraded when new functionality is added.
By iteratively upgrading versions in new services, differences are fewer, so that upgrading to Spring 2.0 first, then to 2.1, finally to Java 11 was piece of cake.
Sooner or later, you’ll have to denormalize
In a microservices architecture, you don’t have a common database. Efficiency will demand you to denormalize your data across services. For instance, your user profile may end stored in several databases. Maybe, they are slightly different versions depending on the needs of your service.
Learn to live with outdated data
This is a consequence of denormalization and efficiency: you won’t have all data updated in every service. You have to reconsider if you need the last version of that data to operate or you can survive with an outdated one while the fresh version arrives.
This entails eventual consistency, what we will talk about that in some other post.
Makes me design better
As sharing data is more complicated, it forces you to define cleaner concepts and design better APIs. At first, it seems so slow and overwhelming. Once you have a handful of services, pieces start to fit together easily, development speeds up and microservices start to pay off.