undefined | Better HN

0 pointsDanielBMarkham11y ago0 comments

Being old and cantankerous, my feeling is that we've tooled up about 400 times more than we need for microservices and the cloud -- a good programmer could/should be able to construct and maintain most small-to-medium-sized projects without a lot of third-party tools.

As an Agile coach, what I find interesting is conveying the philosophy of the work. I am nowhere near being a code ninja any more, but the way you think about writing the application is the most important part of doing the work.

But who knows? We'll see.

EDIT: To be a little clearer, message bus? You sure you need a full-bore bus? Make it work with simple files. Take a look at your volume. If you code it correctly from the start, adding on new stuff is easy. If you start with lots of frameworks and such, you can get caught up in complexities that are orthogonal to your mission. One of the beauties of going full functional is that it makes you focus on whether the dang thing is working or not. In an OO environment, many times you get lost in the "wiring" of the construction, making sure you implement the correct interfaces, paying attention to Demeter's Law and the rest. The end of the week comes and all you've got is forty thousand lines of code and 7 new dlls in your build.

0 comments

3 comments · 1 top-level

CWuestefeld11y ago· 2 in thread

I suspect that getting our developers to embrace not only this new architecture, but also the new paradigm of functional programming is a bridge too far.

Regarding the "full-bore bus" question, I see it being that way for two reasons:

1. Distributed architecture. I think that the way to foster simple deployment of updates services is making them distinct deployable units, and the most obvious way to do that is to put each on its own cluster of servers - although in most cases this is way overkill in scale. And I think that if the services are on different machines, that pushes away from a really simple approach like your idea of files, toward something more sophisticated. On the other hand, perhaps there's a good way to let the services be co-resident by using docker, which I don't yet know very well.

2. Capacity. Although most of the system isn't too heavy, I've got a couple services that are used ubiquitously, and probably do need serious high-performance. First, the legacy system at peak is handling about 25 product pricing queries per second (our pricing is customer specific and based on near-time availability from suppliers). Second, we have not just localization of text, but customer-specific text, so every bit of text everywhere needs to come from that customization engine, although I suspect that this may wind up being addressed more as caches at the UI layer.

DanielBMarkhamOP11y ago

What I should do, once I finish up the basic functionality (which could take a month or two working part-time), is copy this over to an empty box(es) and pound the hell out of it; see how much volume it can handle.

My gut tells me the Ubuntu O/S can take quite a bruising. It'd be interesting to find out. Also there'd be some good lessons in there :)

Remember, the goal of microservices is to completely decouple processing so that you can completely configure the cloud graph any way you'd like. A microservices OO construct by definition would have to do a lot of honking around with the CPU before we got to the "work" part.

Of course what works for one team wouldn't work for another. Fun stuff to play around with, though.

CWuestefeld11y ago

A microservices OO construct by definition would have to do a lot of honking around with the CPU before we got to the "work" part.

No doubt. While I'm enamored with OO myself (having begun my professional life in the late 80s when it was the thing), I think that anything OO would be internal to a given service, and the interfaces between services would be much more conventional, most likely a simply REST approach.

j / k navigate · click thread line to collapse