The Cloud migration moves us from a large data center into many smaller AWS accounts. A (legacy) monolithic application is cut into many smaller microservices.
Internal data center communication becomes exposed communication between different AWS accounts and VPCs. Internal function calls are replaced with remote API calls. Both require much more attention to security, necessitate an authentication framework and add significant latency to the platform.
A failed data center takes down the entire platform while a failed AWS account will only take down some function. An uncaught exception will crash the entire monolith while a crashed microservice will leave the others running undisturbed.
Internal service dependencies turn into external WAN dependencies. Library dependencies inside the monolith turn into service dependencies between microservices. Cyclic dependencies remain a deadly foe.
Team responsibilities shift from feeling responsible for a small part of the platform to being responsible for entire AWS accounts or only their own microservices.
And much more...
If it looks similar, maybe we can learn something from this. I strongly believe that many structural and conceptional considerations apply equally to a Cloud migration and to a microservices journey:
- Fighting complexity through downsizing.
- Complexity shifts from inside to outside. New ways to manage this complexity emerge.
- Keeping latency in check is key factor to success.
- Need much more advanced tooling to properly handle the scale out of managed entities.
- Less centralization of common concerns leads to more wasted effort and resources. Accept this.
- Success and failure hangs on finding the right seams to cut.
- "Just put it somewhere" usually doesn't work at all.
- Integration tests become more important and difficult.
I learned a lot at this conference, both about microservices and about the direction our Cloud migration should go.
Please add your learnings in the comments.