If All Men Were Angels…

If all men were angels, no government would be necessary.

James Madison made the case that no system is perfect precisely because people aren’t perfect. That was, admittedly, a defense of a political revolutionary moment, but it holds true in software design as well.

Mark Little, vice president of engineering for middleware at Red Hat, has a blog post on this topic this week on jboss.org. The entire post is terrific (and readably brief), but there are a couple of points worth highlighting. His premise starts with the idea of what causes (or devolves) a system into a monolith, and he points to this:

Lack of architect (leadership); the original architect(s) leave the project and those who come in to replace them (if they are replaced) can’t control the developers or perhaps don’t understand the architecture enough to ensure it remains “pure”. Likewise, different developers coming into the project to either add to or replace those there already, can dilute the group knowledge and understanding of the architecture, leading to unforeseen and accidental divergence from the original plan.

What leads to an inflexible, centralized monolith application is, ironically, a lack of central vision. Mark sums it up with a really good point about the risks in microservice architectures:

I believe in and understand the need for distributed systems composed of (micro) services. However, what worries me about some of the current emphasis around microservices is that somehow they will naturally result in a better architecture. That’s simply not the case. If you don’t put in to place the right processes, design reviews, architecture reviews, architects etc. to prevent or forestall a local monolith then you’ve no hope of achieving a good microservices architecture. [emphasis added]

This is such an amazing point, it bears repeating. There is frequently this unspoken, sometimes unrecognized, belief that The Next Good Thing will some how solve all of the issues of the Last Good Thing without requiring special effort. But there are no perfect systems — clear planning, good communication, good team processes are required no matter what architectural pattern you’re using to develop your applications.

 

“Tech Preview”: A Look at Wildfly Swarm

The story of Wildfly Swarm, from a business perspective, is kind of a story of microservices. Microservices are small, isolated, and focused service applications; as an architecture, microservices is an approach that decomposes larger systems into those smaller, focused, isolated services. These services talk to each other through a shared, common API, but are otherwise independent in design and deployment. Microservices, then, are frequently aligned with DevOps – which uses small, agile teams to quickly develop and push software for continuous integration (of systems) and continuous delivery (of software).

But what is Wildfly Swarm, in that context.

Continue reading ““Tech Preview”: A Look at Wildfly Swarm”

Intro to Microservices

An increasingly common buzzword in cloud computing is microservices. Like a lot of things associated with cloud technologies, a precise definition is difficult to find — and it can mean a lot of things to a lot of different people, depending on the context. Since this is a blog devoted to middleware issues, I want to define microservices within the context of that middle layer in computing, for application development.

A Definition

Microservices is an architectural approach for a software system. Meaning, it defines how individual services fit together and how those services are constructed (like, general constraints or best practices). What sets microservices apart from other architectural approaches is that it treats each service as a discrete and independent part of the architecture. That means that services themselves (within that system) have very clear definitions:

Continue reading “Intro to Microservices”

  • Page 2 of 2
  • <
  • 1
  • 2