Live data from Hacker News

The Death of Microservice Madness in 2018

dwmkerr.com

321–330 of 469 posts

Re: The Death of Microservice Madness in 2018

#321
post #118

Earlier quoted context omitted.

The key to microservices is a framework and tooling around them to make them work for you. Release management, AuthN/AuthZ, compilation, composition, service lookup, etc. should all be "out-of-the-box" before microservices should ever be considered. Otherwise the O(n) gains you get in modularity turn into O(n) FML.

Would love to hear some peoples' thoughts on good contenders in each of these areas. What are some good boxes to get these out of in 2018?

Release Management. It's not what the cool kids are doing but Microsoft's Visual Studio Team Services is the easiest CI/CD solution I've ever used.

Service Lookup - Hashicorp's Consul.

Authorization/Authentication - I've played with Hashicorp's Vault. It seems overly complicated but the advantage is that it doesn't tie you to a single solution and it can use almost anything as a back end. I haven't had to solve that problem yet.

Re: The Death of Microservice Madness in 2018

#322
post #169

Earlier quoted context omitted.

> The good developers write code that can be replaced, rewritten, or rescaled later. You make a very good point. Over the years, I learnt that almost nobody except the developer and maybe one or two peer-developers cares about good quality code. The management just wants to ship services/products. They don't care how good the code is. All they care is that they can meet their deadlines. Of course, good quality code c…

> good quality code can increase the chance of meeting deadlines, but working long hours can also increase the chance of meeting deadlines. No, that's not true, except in a very superficial sense. Yes long hours _can_ increase the chance of meeting deadlines... but often, it doesn't - or more precisely, it only works if the code quality is decent. "Code quality" is not about following whatever patterns are en vogue t…

As peopleware says, overtime is never free. Yes, it definitely can help you meet deadlines if its done every so often, but if its a regular thing, then “normal” productivity will be much lower, so it can’t sustainably help meet deadlines again and again and again.

Re: The Death of Microservice Madness in 2018

#323
post #169

Earlier quoted context omitted.

> In my opinion, only the extremely good developers seem to comprehend that they are almost always writing what will be considered the "technical debt" of 5 years from now when paradigms shift again. I've also seen really bad developers with that attitude: it's all crap, so just ship whatever already. The good developers write code that can be replaced, rewritten, or rescaled later. Though, charitably, both monolithi…

> The good developers write code that can be replaced, rewritten, or rescaled later. You make a very good point. Over the years, I learnt that almost nobody except the developer and maybe one or two peer-developers cares about good quality code. The management just wants to ship services/products. They don't care how good the code is. All they care is that they can meet their deadlines. Of course, good quality code c…

> I learnt that almost nobody except the developer and maybe one or two peer-developers cares about good quality code.

No, but they do care that this seemingly (to them) trivial change a year later takes two weeks instead of half a day.

> How do you retain your motivation to be a good developer in such a situation?

I honestly don’t know. I’m currently taking a little time out from work, but I’m dreading going back in a month because right now, I am completely disinterested in computers and especially software, things I used to love and be incredibly passionate about. Now with stuff like meltdown and spectre, technology just seems like this dumb house of cards and I have no energy for this BS. I’m pretty sure its burnout and it will pass eventually, but I just hope it does so soon as I don’t know how else to pay the bills.

On the plus side, I’ve spent a lot less time at the computer these last few weeks and spent time on other interests, including learning sleight of hand and card magic. :-P

Re: The Death of Microservice Madness in 2018

#324
post #156

Earlier quoted context omitted.

I downvoted because without context this just seems like the typical know-it-all statement from someone who has yet to realize how little they really know. There's no attempt to even try to appreciate how their situation may be different, just the default disdain so typical from some professionals incapable of thinking outside of their own perspective.

I think the context is pretty clear: microservices. If it takes 10 people to manage one service, it is not a microservice by definition. It is more like a 10x-microservice or a macroservice.

It's not the number of people that are micro, it's the scope of the service... So what is the right level of manpower for a scoped service with unspecified operational demands? Unknowable.

The definition isn't small teams, per se, it's a small area of responsibility with singular focus. A lego block instead of duplo. That lends itself very well to small teams, but you could reasonably have 100 people working on a service and call it "micro".

Reason being: if those 100 people weren't working on their scoped 'microservice' they would be part of a much, much, much larger pool working on the shared 'product', 'platform', or 'service' that contains that exact same functionality, only without the clarity/scalability of application boundaries surrounding the individual service components.

That's not to say microservices are ideal, just that the size of "micro" is highly relative to ongoing operations.

Re: The Death of Microservice Madness in 2018

#325

Great article, but I'd like to dispute one point: > A new version of the subscriptions service may store data in the subscriptions database in a different shape. If you are running both services in parallel, you are running the system with two schemas at once. Microservices should manage their own separate data stores and communicate with others through a well-defined API. Only then services can evolve independently,…

They might be talking about a slow rollout.

If that was the case then it wouldn't be anything specific to microservices.

Re: The Death of Microservice Madness in 2018

#326

There's a ton of stuff here -- enough for a book or two. I loved the article although I might take issue with several of the smaller points. It's way too much to go into on an HN thread. There's just so many topics that all come together here: stateless programming, pure FP, NetOps, DevOps, and so on. It feels like one of those cross-discipline discussions where it's either really simple -- or really complex. In fact…

Hi Daniel, It's weird you mention that, I was just chatting to a colleague the other day on this topic, and I rooted out this old article which I loved: www.slideshare.net/ScottWlaschin/ddd-with-fsharptypesystemlondonndc2013 I was lucky enough to work on a big F# project a while ago and really enjoyed the experience, it was the first time I'd done any functional programming in a professional context and I miss it now…

Hey Dave,

No problem. There was a ton of good stuff in there! I saved it to refer back to it later. :)

As a tech coach, I teach good programming skills, which mostly ends up being TDD and other good coding skills for OOP folks. But I've become a huge pure FP fan over the past decade, learning it all on my own just by struggling through it.

So as a coach, I'm seeing more and more of these microservice train wrecks. I'm also seeing a ton of people who don't understand microservices come online and bitch about how they don't work.

Wlaschin's book goes into building a pure FP system from the top-down -- something I never considered doing (I've never coached or worked in a large pure FP shop). Of course, if you build it out that way, it really doesn't matter how you splice up the code or where it goes. You can do monolith, serverless, microservices, whatever.

I liked the process described in the book a lot. It describes to me how you can have 50 people and 100 microservices and make it all work. (Although everything you point out is still an issue, many of the pure FP techniques mitigate them.) Feels a lot like BDUF, though, which kinda bugs me.

I sat down with Uncle Bob last month and spend a week showing him F#. TDD didn't seem to work that well, but maybe I missed it. There's just nothing to test in simple transforms, and you want to keep using simple transforms as much as you can. I think we need to evolve a TDD-like process for growing systems in pure FP from the ground-up. I'll probably cogitate on this for a few years and end up writing something. If you know of any good resources, please send them my way!

Re: The Death of Microservice Madness in 2018

#327

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…

While I'm not arguing with you, I have had a different experience working with developers and microservices, perhaps because the teams have been more seasoned/experienced and there is more of a collaborative environment. I found that a lot of the time developers start moving towards microservices when they find that a monolithic app becomes too difficult to work on. For example, multiple teams working on the same cod…

I think that kind of process, slow decomposition based on performance and requirements, is the only sane approach.

It's also reflected in how we manage code at the micro-level: collecting related logic into a module until it becomes unwieldy and then separating out independent sub-functionality into their own modules and dependencies as they grow...

There is no right size for a class. Smaller is better, but the ideal is "right sizing". What's right? Well, that's tricky, but whatever doesn't hurt is pretty ok.

There's no right size for a service. Smaller is better, but...

Re: The Death of Microservice Madness in 2018

#328

Earlier quoted context omitted.

Great analogy. I tried to paint my own flat. Was a disaster.

I've tried to hang sheet rock. How hard could it be? It certainly looks easy. A disaster for me, too.

For us non-english speakers - "sheetrock" == drywall.

I find I can do most such works better than (average) professionals, but it takes a lot of time to learn, prepare, execute (+ sometimes re-execute) and clean. It all depends on when you are satisfied with the result.

Re: The Death of Microservice Madness in 2018

#329
post #15

Biggest issue with microservices: "Microservices can be monoliths in disguise" -- I'd omit the can and say 99% of the time are . It's not a microservice if you have API dependencies. It's (probably) not a microservice if you access a global data store. A microservice should generally not have side effects. Microservices are supposed to be great not just because of the ease of deployment, but it's also supposed to mak…

Once when starting a new gig I inherited a "microservices" architecture. They were having performance problems and "needed" to migrate to microservices. They developed 12 seperate applications, all in the same repo, deployed independently it's own JVM. Of course if you were using microservices, you needed docker as well, so they had also developed a giant docker container containing all 12 microservices which they de…

Sounds like they don't understand why it's called a microservice to begin with. They're not supposed to be solutions an entire piece of software, just dedicated bits at least that's what I'd figure with a name such as "micro". When we adopted microservices at my job (idk if Azure Functions count or not) we did it because we had 1 task we needed taken out of our main application for performance concerns and because we knew it would involve way more work to implement (.NET Framework codebase being ported to .NET Core which meant the dependencies from .NET Framework did not work anymore in .NET Core) but we eventually turned it into a WebAPI instead due to limitations of Azure Functions for what we wanted to do (process imagery of sorts).
Post reply on HN