However, setting the bitching about re-inventing the wheel aside, there is a new contender for human non-consumption these days. It fits in nicely with the new name of my site, being used by tools such as Docker and Kubernetes, and its name is YAML, for “Yet Another Meta-Language”… Oh no! “YAML ain’t Meta Language“? Ye gods, yet another recursive name! (YARN) Yet another human-readable data serialization language, (YAHRDS) and this one is a doozy! Like our favourites of lots of years ago it uses whitespace to denote structure: start a line of text with more spaces then the last, and you are apparently detailing whatever was in the last line. Worse: if you want the detail to stop, just start the line with the same amount of whitespace as the level you want to return to. So if there are a lot of lines with details, you have to hunt upwards with a ruler to find out how many levels were just “closed”. YUC! (You Unintentionally Cringe)
‘scuse me for the late well-wishing, but there you go! 🙂 I’ve been busy with helping my eldest move to her first student-apartment-room-thingy. Next I started redecorating her ‘old’ room for use by the undersigned. Takes a bit longer than planned, but I can almost start flying virtually again.
If a microservice in the cloud stops responding,
and no logs were generated,
did it fail at all?
Suppose I have two applications, one a “classical” monolith, called so even though it was built using a multi-tiered architecture, the other using a microservices architecture. Furthermore, lets keep it simple and assume the functional requirements were the same, so they both provide the same functionality to the organisation and users. What can we say about how difficult they are to build and run? How do they compare? Why would I prefer the one over the other?
The monolith looks like the easy winner in build effort if I were starting from scratch, having the advantage of a simple infrastructure and application design. Hokay, now let’s add in a sense of reality: I have performance requirements, splitting the users in internal (employees), external (customers), and IT staff. (“keep everything running”) So the infrastructure needs a bit more thought; probably a separate database server and web-application server. Maybe a separate web-application server for the internal users, so their work won’t inconvenience the customers and vice-versa, and a common back-office system to tie it all together. Security is a thing as well, so set up a secure directory server to manage accounts, a DMZ around the front-end to secure the back-end further, some DDOS protection, you know the drill.
We’re hitting all the important points, so let’s take a look at the alternative: We take an account at one of the major cloud providers, select the appropriate lego-blocks from the catalogue, and start filling it with components. Funny thing is, this sounds easier, because we don’t have a lot of the infrastructure hassles.
Fast forward to the working application and we’re ready to throw a wrench into the system. Monkey wrench? Yeah, a Chaos Monkey wrench. Customers start calling that the site isn’t working. Now what?
A developer presented a new module, saying: “If you call this a microservice,
you oppose its reality. If you do not call it a microservice, you ignore a fact.
Now what do you wish to call it?”
Microservices are in full swing towards the “Trough of disillusionment”. Practically everyone has heard about them, and we have famous “poster children”, with Netflix probably as the most used example. Many are trying for it, and lots have failed or are coping with problems following their introduction. Interestingly though, there is no authoritative definition of what a “microservice” actually entails, mainly because that would imply you have a clear target to shoot for, and the failures show the target isn’t clear at all.
Dennis Schmidt wrote a book called “Way-farer”, which plays in some distant future (as envisioned back in 1978) where men have come to the planet of Kensho. In it, a young man called Jerome starts on his road to enlightenment through the Way of the Sword. In the mountains it is rumored that a Master lives, who might teach him, if he manages to convince the Master to do so. He eventually finds the master, and, when confronting him with his request, is denied. He perseveres however, and eventually the master confronts him about his motives. This confrontation is perfectly reusable for the quest of many into the “Way of Microservices”. So here is my adaptation:
The Master squatted, peering into his eyes, his face only a few inches from Jerome’s.
“Who are you?” Abrupt. Harsh.
“What are you?”
“What do you seek?”
“The Way of the Microservice.”
For a Software Development professional, one of the earliest truths you learn is that estimating the delivery effort for new system is surprisingly hard. A project manager at IBM told me once, back in the nineties, that the difference between a senior developer and a junior one, can be found in the finely tuned padding he or she adds to their estimates. This is not to say that you won’t be able to quickly develop a sense for the amount of work needed if the subject domain is in your field of experience, but what you learn over time is how much to add for what wasn’t specified explicitly. Frederick Brooks (of The Mythical Man-Month fame) called this the difference between essential complexity and accidental complexity. It leads to the familiar frustration with developers that, even though their estimates were spot-on, the system was nevertheless late, and they get blamed for the discrepancy.
An often heard remark, especially at management level, is that software development needs to get “industrialized”: just like the production of cars and kitchen appliances, writing software needs to becomes standardized to the extent that estimates necessarily improve. This is related to the idea that a higher level of maturity in the software development process will automatically cause the costs to come down. What really messes up these expectations however, is that, in a very fundamental way, producing software is not like producing a car.
Software Quality is a nice subject to write about. So much to say with plenty of viewpoints to choose from. Wikipedia tells me it is about functional quality (how well it complies or conforms with design or requirements), or structural quality. (the non-functional aspects) There’s an ISO standard on Software Quality Requirements and Evaluation, and another one on Process Improvement and Capability Determination. Via that route we can then continue into the process for making a quality product and invoke CMMI; the integrated model for maturity capabilities.
Actually, there’s so much on the subject you’d wonder why it even is an issue. I personally think there is a simple reason for all this: for software, quality is an inherently vague quality! [sic]