Why our team cancelled our move to microservices
steven-lemon182.medium.com
Why our team cancelled our move to microservices
1–10 of 243 posts
Re: Why our team cancelled our move to microservices
#2> A benefit of microservices is that each team can be responsible for releasing their services independently and without coordination with other teams.
Sounds almost sarcastic. How do you deliver API changes without alerting other teams?
Re: Why our team cancelled our move to microservices
#3> A benefit of microservices is that each team can be responsible for releasing their services independently and without coordination with other teams. Sounds almost sarcastic. How do you deliver API changes without alerting other teams?
Proper deprecation procedures. you can document how you uniformly deprecate and remove APIs. This is a strength of using something like OpenAPI for documentation, or GraphQL, for instance. It is then the responsibility of a consumer to deal with these deprecation(s). On the most basic level you could also do versioning, though its not my recommendation
Document and set expectations accordingly. I've done this move before breaking apart a monolith into separate micro services and this is key. Spending more time on good documentation is generally a good idea regardless.
I'm assuming we're not talking about public facing APIs. That's a situation where versioning might make a lot more sense.
Re: Why our team cancelled our move to microservices
#4> A benefit of microservices is that each team can be responsible for releasing their services independently and without coordination with other teams. Sounds almost sarcastic. How do you deliver API changes without alerting other teams?
I'd guess that 90-95% of tickets do not alter a existing API in a non-backwards compatible way
Re: Why our team cancelled our move to microservices
#5> A benefit of microservices is that each team can be responsible for releasing their services independently and without coordination with other teams. Sounds almost sarcastic. How do you deliver API changes without alerting other teams?
Do you not version APIs you design?
When engineering an API meant for consumption by disparate services it’s imperative to provide back words compatibility.
This is pretty basic stuff anyone designing a serious API should be taking into account.
Re: Why our team cancelled our move to microservices
#6It took me a while to accept that microservices are better. Not in every case, but in a surprising number of cases. They really shine when combined with serverless computing. Clear seperation of code by a networking call is the next logical step in the encapsulation principle of object oriented programming. We hide the implementation details and only expose an interface, which creates seperation and forces us to stop sphagetti logic. Microservices are the enxt step in that design pattern, and only with the improvement in container technology and cloud computing has this become achievable (in the sense of there not being so much operations and complexity overhead).
Re: Why our team cancelled our move to microservices
#7The term "Monolith" was devised by people who wanted to brand microservices as newer and superior.
It's almost as if in order to succeed these days you need to discredit and disparage your competition rather than simply having a better product, and that's why I don't buy into buzz words at all.
If it's not broken, don't fix it... Microservices are relatively new and unproven. The way the world has rushed to dive into microservice infrastructure only highlights reckless spending and waste that is characteristic of overpriced goods and high taxes that are constantly in turn thrust upon us, as consumers.
Microservice architecture is also inherently designed to lock a customer into very specific tools that make future migration to any other platform a very costly decision in most cases... Thereby locking a customer into platform-specific dependency. Microservices architecture also introduces the ability for providers to charge for each specific service as a utility... Instead of being charged for one single server annually, on microservices you can be charged for many individual components that run your app independently, and when usage skyrockets, it's a sticker shock that you can only stop by going offline.
We have also seen enough failures and pain points within microservice and even cloud architectures over the past two years alone to raise questions about whether or not it it indeed a better solution.
We need to stop disparaging traditional (non-cloud) hosting and solutions that aren't obsolete at all in this manner, and focus on what works, what is secure, and what is cost effective in order to stay sustainable into the future.
The more we allow marketing minds to take control of our IT decisions over reasonable technical minds, the more costly it will be to us all over time, no matter what salary we make. Bog tech firms will hate me for saying this, but any human in the chain can tell that reckless drive for weak/vulnerable/costly/and over-complex IT solutions cannot be sustained as a viable long-term business sales strategy anyway.
Re: Why our team cancelled our move to microservices
#8Is there any way to read without login?
Re: Why our team cancelled our move to microservices
#9> A benefit of microservices is that each team can be responsible for releasing their services independently and without coordination with other teams. Sounds almost sarcastic. How do you deliver API changes without alerting other teams?
Generally speaking if you're adding another field to a JSON or something, that doesn't really break the parser [1] or affect downstream. While you should still probably let the downstream teams know, it's not necessarily going to break anyone's code.
[1] I'm aware that that's not always true (e.g. adding a field that's ridiculously large choking up the parser).
Re: Why our team cancelled our move to microservices
#10"Microservices had been sold to us as the ideal architectural for perhaps a year now."
When he learn that there is no ideal architectural in software? )