- Who’s at the Helm? [0]
- Microservices, hard as 1, 2, 3 - You can move it but complexity is still here [1]
- Microservices — architecture nihilism in minimalism's clothes [2]
- Do I Really Need Kubernetes? [3]
- Your team might not need Kubernetes [4]
I doubt that any of those articles could convince higher management. I don't know what a "respected source" actually means. I general I believe that advice from consulting agency and cloud providers should be taken with a grain of salt.
If you drew the same conclusion from the "Who’s at the Helm?" article than I, there is only one way out which is a curated container catalog. VMware's Tanzu Application Catalog [5] is the only product in that space I'm aware of. I have quoted the price tag on HN, I think it was removed since that, so I won't repeat it here again. In any way it was magnitudes higher than the EKS base price which already seen as a showstopper by many small shops. Bottom line is: it is really hard and really expensive to operate containers in a secure manner. Probably too hard and too expensive that it would be a good idea to start with it before you actually need it.
What I really don't get about microservices is the performance aspect. Like cache << memory << disk << network in terms of time needed to read/write, and it seems to me that microservices are particularly prone to this by often using HTTP calls.
Sure, you can run them on the same box, but it's very easy not to, and I imagine that this will absolutely crater performance (at least in the DS/ML stuff I do).
Disk is often slower than the network now. You do need to keep an eye on this. However, using tools like gRPC instead of wasteful JSON REST calls makes a huge difference and brings other benefits too.
Typically speaking you're adding submillisecond latency per external call, or you've done something wrong.
Something wrong can include incorrectly organizing your system. Two separate services that constantly chat with one another should probably be considered as candidates to merge into one, for example.
Deployment matters a lot. I see people mocking systems like Kubernetes and tools like service meshes, probably because they don't understand this critical and hugely beneficial capability they bring which is to organize communication on the bases of (amongst other things) locality and system topology automatically.
In the end, most people seem to totally miss the real reason that "micro" services (the "micro" part should really be ignored today) are beneficial. Hint: it's not a technical problem being solved. It's a people problem. Service oriented architectures give very clear boundaries around which a development organization can structure in a way that allows parallel delivery.
The biggest problem any growing organization will face is: they don't pay attention is contention (yes like as in concurrency/locks/etc.) across the development team(s).
I have personally witnessed and worked with a 400+ person monolithic development organization. This was essentially a "unicorn" and an exception that proves the rule. The one and only reason this organization was successful was because they had top to bottom extreme coordination managed by a very small group that worked effectively together. Without that tight central orchestration it would've been a nightmare.
Most organizations can't orchestrate a 7 person team effectively, good luck getting 200 to share a monolith well. So you break up the org and the architecture follows, see: Conway's Law. It goes both ways, too. You break up the architecture and the org can follow.
With that in mind, it's extremely important to get your boundaries right and for the love of all that is sane in a daily job, don't break it up too much. So many organizations would triple or quadruple their productivity breaking a monolith into literally 2 parts. If you can do 3-5 that's cool, amazing! Just because you can see the dotted lines between 25 different potential services doesn't mean your organization will tolerate that.
Anyway that was a diatribe.
TL;DR: "micro" services solve PEOPLE problems, moreso than technical ones, and the price you pay is additional architectural and delivery challenges which you must balance well and plan for
Couldn’t agree more. I can agree that premature abstraction is bad. But unnecessarily duplicated code outweighs this by orders of magnitude, in my experience. So stay DRY, and later when you hit that 1 case in 100 where the code needs to diverge, it’s easy enough to copy/paste.
I want to frame your first sentence. Abstract code discussions are absurd. I’ve learnt to mostly ignore programming blogs if they don’t include some concrete code.
Most code maintenance issues don't really appear until a relatively large amount of code and code evolution is involved. It's hard to include that in a blog post while keeping it digestible for the average reader.
In a small example, excessive duplication is not a problem, and excessive DRYness is not a problem.
Therefore, it makes some sense to me to leave out code, and just hope the reader has personal experience to draw relevant examples from.
I’ve had this too, and only when on my back. I had a pounding sensation in my head (heart beat), an ominous presence, and the feeling that I’d die if I didn’t force myself awake. I’m convinced this is related to sleep apnea. I try to avoid sleeping on my back now.
Yes, it feels like I’ve stopped breathing for a minute or longer (which might actually be the case). On a few occasions I hear screaming, which I believe is my brain trying to wake me up due to low oxygen.
