Life on the Edge

Posted on 21-05-2018 by blaverman

“But even more important,” he said, “is the way complex systems seem to
strike a balance between the need for order and the imperative to change.
Complex systems tend to locate themselves at a place we call ‘the edge of chaos.'”
Ian Malcolm at the Santa Fe Institute

 

If you’ve been following the announcements surrounding the Java platform, you may have noticed something peculiar happening with the latest Java SE versions. Hardly has the ink dried on books describing the Java 9 release, and we’re already on Java 10. Even more unusual: if you go to Oracle’s Java downloads, you’ll find sections on Java 10 and Java 8, but 9 is gone already, and that in only half a year! The obvious reason for this is Oracle’s new release cadence, where so-called “Long-Term-Release” versions will still use the 3-year cadence, but between these LTS versions Oracle has moved to a 6-month cadence. The reasoning: “developers prefer rapid innovation”. While on the whole Oracle had been getting a lot of flak for it’s slow pace, the combination of a faster pace with rapid removal of older versions will come as a shock for many.

If you compare this with what has happened in the world of Browsers, then it shouldn’t come as a big surprise, because there we see that “big” release numbers have already vanished into oblivion. Who still remembers the toils of “IE fill-in-your-favorite-number” compatibility, especially when catering to slow-changing corporations? Nowadays browser version numbers are hardly ever mentioned, and they range from 17 for Microsoft Edge to 66 for Google Chrome. Sites like “Can I use?” (https://caniuse.com/) provide detailed analyses of the different versions and how well they support HTML, CSS, and other standards, and specialized JavaScript libraries dynamically add support for missing bits.

So is this increased pace really a Good Thing™, simply a natural and inevitable evolution, or is Gartner finally right with its continuing predictions of doom for the Java platform?

Continue reading →

Posted in Agile, Microservices, Programming Languages, Software Architecture | Leave a comment

Agile Architecture, or When not “to Architect”

Posted on 30-03-2018 by blaverman

The sword in the scabbard is a price beyond compare.
Jerome, the first Wayfarer.

Agile Architecture is an interesting subject from a people point of view, especially when funny movies are circulated about a house-building team embracing “Agile”. The movie shows how the team starts constructing happily, but stops somewhere halfway after finishing the ground floor, because other priorities pop up. The point raised is ostensibly that some things simply don’t fit with a agile way of working, comparable to a manager stating “I don’t need to be Agile; I know what I want! Just build it already!” Naturally, when the poster of the movie is cornered about his or her opinions on Agile Software Development, the reply invariably goes towards the comedy value of the content rather than the point it appears to make. So far however, I have yet to find someone making the correct observation that this team lacked a sense of their customer, and probably a Product Owner. As Dave Thomas argued in his presentation “Agile is dead” at GOTO 2015, agility is about taking small steps towards your goal, and after every step evaluating what it did for you. Being able to change direction after every step is what makes you agile, not whether you actually do change direction.

When I read Robert C. Martin’s book “Clean Architecture”, I was intrigued by a chapter called “Details”, which started with “The Database is a Detail”. It discusses the application of agile architecture, and not over-architecting when a simple solution will do. The point is that even the choice of your database technology is a detail which might not be important enough to solve up-front. If, like me, you work in a large organization which values the selection of a standardized Relational Database, that approach can be quite a challenge.

Continue reading →

Posted in Agile, Software Architecture | Leave a comment

Closing the Knowledge Gap

Posted on 11-02-2018 by blaverman

If they were handing out Lamborghini’s for free, let’s say the Aventador, would you take one? I know that for myself, this would be a bit of a poser. I’ve seen enough lotteries where you could win dreamcars, but in the back of my head I would always admit that I would probably put it up for sale. Let’s be really honest here; I definitely would like to take it for a drive, but I don’t have any sports-driving skills, it’s way to big for most parking spots, and having to cross the 5 speedbumps in my neighbourhood just to get home would completely trash the spoilers. But the real long-term killer is the required budget for upkeep; maintenance costs alone would kill any chance of a decent holiday for the family. Even if we stretch reality a bit further and include free spare parts, you need specialized tools and knowledge, and you need the room to house it properly. In the Netherlands that last bit can be a real killer.

That all said, if I’m planning to do a lot of miles, nobody can deny that a Lamborghini can really take care of that! But the thing that really jumps into my mind about them is mr Clarkson of Top Gear fame, who enthasiastically explains how you can actually switch off most “protection” to get the best performance, and end up with a car that feels like it is actively trying to kill you. A bit dramatized, I admit, but he was definitely on edge about his personal safety in that car, while pushing it to its limits.

Now read on as I try to revert back to software and applications, while maintaining relevance to the Lamborghini introduction.

Continue reading →

Posted in Microservices, Software Architecture, Software Engineering, Tools | Leave a comment

Turning your application on its head

Posted on 03-02-2018 by blaverman

If nothing what you do wil do, then what do you do?
Hisamatsu Shin’ichi (1889-1980)

So I’ve started by telling you that the Way of the Microservice has to do with quality, that this aspect is more important than the obvious aspects of size and deployment, and that trying to be like Netflix is likely to trip you up if you don’t get the quality bit right. Even Gartner, that ultimate fond of business wisdom, warns its customers that “You are not Netflix.” Bummer. So, why are we even going this path? I mean, apart from the lofty goal of delivering high-quality software, which I hope you’re not against. It’s most likely this nagging feeling that you want affordable quality, not quality at any cost.

An important thing you’re going to get from using a microservices architecture, and totally worth the (apperent) trouble, is increased autonomy. If your “application” is built as a group of cooperating small processes, and they adhere to those principles of loose coupling and high cohesion, you gain a lot of flexibility. Since the components are small, making sure they are secure and fault-tolerant is also a lot easier. Luckily there is a fairly simple trick to help you achieve the increased independence: stop building applications that move data around, but model the flow of data first, and let your microservices process or produce them: Implement a Data-Driven Architecture.

Continue reading →

Posted in Microservices, Software Architecture | Leave a comment

XML still not fit for human consumption, and neither is YAML

Posted on 15-01-2018 by blaverman

A while back I wrote about XML (The Problem with XML), arguing that it is essentially great for computers, but definitely less so for humans. Since then, XML’s popularity in the enterprise world hasn’t really diminished that much, although we do have a strong competitor in JSON (the JavaScript Object Notation) for REST calls over the public Internet. But wait, more is happening! Binary is BACK thanks to our friends at Google, who argued that, within the confines of the (corporate) local network, binary is pretty acceptable, and way more compact and thus efficient. They named their baby “protobuf” for Protocol Buffers. Duh! Who’d have thought that? I mean, apart from any young upcoming developer… and most older ones as well. Even then, admitting I haven’t looked at the underlying encoding of the bits and bytes, didn’t we already have something like that with CORBA? Or ASN.1?

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)

Posted in Uncategorized | Leave a comment

Happy New Year!

Posted on 15-01-2018 by blaverman

‘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.

Posted in Uncategorized | Leave a comment

Why are Microservices so hard?

Posted on 04-12-2017 by blaverman

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?

Continue reading →

Posted in Uncategorized | Leave a comment

So what is a Microservice?

Posted on 23-11-2017 by blaverman

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.

Continue reading →

Posted in Agile, Microservices, Software Architecture | Leave a comment

Introducing: Zen and the Art of Microservices

Posted on 19-11-2017 by blaverman

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.
“Jerome.”
“What are you?”
“A Seeker.”
“What do you seek?”
“The Way of the Microservice.”

Continue reading →

Posted in Microservices, Software Architecture, Uncategorized | Leave a comment

Making Software Development effort more predictable

Posted on 25-09-2015 by blaverman

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.

Continue reading →

Posted in Musings, Project Management, Software Engineering, Uncategorized | Tagged , | Leave a comment