Microservices group project

project-thumbnail-2019-microservices
Developed for Riga Technical University (RTU) in 2019
Tags: Planning Microservices Java C# Node.js Vue MySQL DevOps

It's useful to learn from failure and do post-mortems as well!

More information

Many might choose to only talk of their successes, though where's the fun in that? Here's a short story about an abject failure, that was a useful learning experience. A while back, people really bought into the benefits of microservices, along the lines of the Gartner hype cycle.

However, something that few consider are the operational complexities brought on by picking such an architecture, as well as the inevitable overhead of managing various project runtimes and configurations, making it so that picking microservices for smaller projects is likely to lead to failure!

What I did

I tried. I really tried, I think I wrote about 4-5 services in the planned system, set up the infrastructure, even set up CI/CD and helped my course mates out. Sadly, that wasn't enough, because some of the people didn't have professional experience, yet assigning individual services to individual people for them to develop those just isn't good enough - because if their APIs are the furthest thing imaginable from REST and aren't even well suited for solving the issues at hand, the overall system won't work.

What I learnt

It's not enough to have "your" services working. You either succeed or fail as a team, or as an organization. Therefore it's important that you both support your developers, as well as check their work, to make sure that the direction that you're working in is aligned with both the technical requirements, as well as the overall organization goals that you're striving towards.

Page rendered in: 0.01 seconds