5 ms·
I would argue it would be simpler to introduce test coverage tools that automatically call out bad test coverage during code review. Microservices remind me of
by 0xfaded 10y ago
I would argue it would be simpler to introduce test coverage tools that automatically call out bad test coverage during code review.
Microservices remind me of a particular C++ protocol implementation I wrote as a novice programmer. Since the protocol was structured, I had high level classes broken down into simpler classes. e.g.
virtual class Reader {
void read(Buffer *buf);
};
class TCharacter: public Reader {
TString *name;
TList<TStat> *stats;
...
};
class TStat: public Reader {
TWord32 *remaining;
TWord8 *percent;
};
class TWord32: public Reader {
uint32_t v;
};
class TWord8: public Reader {
uint8_t v;
};
And on, and on, and on, and on ...
I thought it was cute that down to the simplest PODT, every type satisfied a well defined `Reader` interface. I hand wrote many constructors, deconstructors, read and several other interface definitions for each type.
Elegant, arguably. Inefficient, yes. Overly complex, undoubtedly.
Every argument for microservices has in some way reminded me of this code, with it's well defined interfaces and overly verbose implementation.
My current strategy is to utilise the crap out of language features to safely achieve what I want in the minimal amount of code possible. In C++ this would be done by initialising the protocol structure classes straight out of the memory buffer, using #pragma pack as required. No error prone constructors / deconstructors / read() required.
Haskell and Scala are two languages I use a lot, and each have powerful type systems which I can use to prevent myself from doing something stupid. Programmable macros are great for removing boilerplate. Want less technical debt? Write less code.
In my own controversial opinion, if somebody can't work out how to modify my code because they can't work out how to correctly update the type definitions, that person has no business modifying my code. Problem solved! Interfaces are well defined and modifiable only by people who truly understand the code.
- ScottBurson 10y ago> Want less technical debt? Write less code. I love this Dijkstra quote: If we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
- bluejekyll 10y agoWhen I was in College, I really only appreciated Dijkstra as a genius who invented neat multi-processing techniques. As a formal Software Engineer, I now consider him to be possibly the most enlightened engineer that's ever existed in the field.
- duaneb 10y ago> As a formal Software Engineer, I now consider him to be possibly the most enlightened engineer that's ever existed in the field. On one hand, his quotes have the ring of wisdom. On the other, the man was famously not an engineer and never brought a software project to fruition, to my knowledge. These aren't necessarily contradictory, but you should keep it in mind. Knuth is much more of an engineer in the sense it's used on HN.
- bluejekyll 10y agoKnuth is brilliant and wonderfully pragmatic, no doubt. I think the greatest thing Knuth really got into me is that code is meant for people, not computers. As to Dijkstra; enlightenment doesn't necessarily mean productive. Some of the least successful people I've ever met, can have absolutely sage like advice. Dijkstra was able to visualize things others could not, and explain novel solutions to those. On top of that he had a deep understanding of the life of a programmer and the complexities faced day in and day out.
- geon 10y ago> Some of the least successful people I've ever met, can have absolutely sage like advice. You learn from mistakes. Unsuccessful = many mistakes?
- jhayward 10y agoThe kind of creativity and acceptance of uncertainty that leads to insight is often at odds with the narrow focus get-it-done tenacity associated with success. Some people have more of the former without the ability to switch to the latter.
- computerex 10y agoThe primary offering of microservices is decoupling and simplicity. They are language agnostic, communicating via HTTP /messaging/pattern matching. It's the opposite of verbose and traditional monolithic architectures that relied on a rich domain model. Microservices should be small enough to be owned by a single developer. With pattern matching, you can extend functionality by creating new microservices instead of modifying existing ones. It boils down to change management. For complex systems, the benefits microservices bring to the table make the overhead cost of maintaining these services worth it.
- 0xfaded 10y ago> Microservices should be small enough to be owned by a single developer This seems bad for code review, and disastrous with turnover. Whoops, now we need to find a scheme engineer whose eccentricities are roughly equivalent to this last guy. There are also ways to achieve microservice-like architectures without requiring multiple code bases. See Actors (scala akka). Streams are an extension which give automatic load balancing. And if you need it to run over the network, akka-remote has you covered.
- hinkley 10y agoI've not been happy with this kind code ownership in the past. Those who want to misbehave have a nice comfortable place to hide out while appearing relevant because they have a monopoly on an idea that they don't have the skills to be responsible for. So then you have your coworker who wrote a wrapper around the code to sanitize all of the inputs and outputs and it's bigger than the actual code and once in a while it guesses wrong about ambiguous data.
- duaneb 10y agoThis somewhat sidesteps an advantage of microservices that they are language agnostic.
- 0xfaded 10y agoI've never been convinced this is an advantage. Ryanair (the discount carrier) has a fleet of 354 boeing-737s. This means they cannot fly some routes the bigger jets can, and other routes they burn more fuel than the smaller jets would. BUUUT ... maintenance and logistics are drastically cheaper and efficient. By analogy, I would argue that costs sunk either in training or hiring for specific skills will pay off in the long run.
- crdoconnor 10y ago>Want less technical debt? Write less code. Also: write less powerful code. * Replace 'clever' metacode with straightforward imperative code where possible. * Replace imperative code with declarative code where possible. * Replace declarative code with configuration where possible.