Hat tip to Stuart Halloway… once again a 10 minute conversation with Stu grew into a combination of code and writing that helped me clarify my thoughts. I've been working on new content for my Monolith to Microservices workshop. As the name implies, we start with a monolith. Everyone gets their own fully operational production environment, running a fork of the code for Lobsters. It's a link sharing site with a small but active group of users.
Continue Reading »architecture
-
Evolving Away From Entities -
Services By Lifecycle This post took a lot longer to pull together than I expected. Not because it was hard to write, but because it was too easy to write too much. Like a pre-bonsai tree, it would grow out of control and get pruned back over and over. In the meantime, I delivered a workshop and spent some lovely holiday time with my family. But it’s a new year now, and January is devoid of holidays so it’s high time I got back to business.
Continue Reading » -
The Entity Service Antipattern In my last post I talked about the need to keep things separated once they've been decoupled. Let's look at one of the ways this breaks down: entity services. If a pattern is a solution to a problem in a context, what is an antipattern? An antipattern is a commonly-rediscovered solution to a problem in a context, that inadvertently creates a resulting context we like less than the original context.
Continue Reading » -
Keep 'Em Separated Software doesn't have any natural boundaries. There are no rivers, mountains, or deserts to separate different pieces of software. If two services interact, then they have a sort of "attractive force" that makes them grow towards each other. The interface between them becomes more specific. Semantic coupling sneaks in. At a certain point, they might as well be one module running in one process. If you're building microservices, you need to make sure they don't grow together into an impenetrable bramble.
Continue Reading » -
Availability and Stability Last post covered technical definitions of fault, error, and failure. In this post we will apply these definitions in a system. Our context is a long-running service or server. It handles requests from many different consumers. Consumers may be human users, as in the case of a web site, or they may be other programs. Engineering literature has many definitions of "availability." For our purpose we will use observed availability.
Continue Reading » -
Fault, Error, Failure Our systems suffer many insults when they contact the real world. Flaky inputs, unreliable networks, and misbehaving users, to name just a few. As we design our components and systems to thrive in the only environment that matters, it pays to have mental schema and language to discuss the issues. A fault is an incorrect internal state in your software. Faults are often introduced at component, module, or subsystem boundaries.
Continue Reading » -
Wittgenstein and Design What does a philosopher born in the 19th Century have to say about software design? More than you might think, particularly his ideas about family resemblance. Wittgenstein used the subject of "games" to illustrate an idea. We'll start with a counter-example. Suppose we operate with the then-prevailing notion that words are defined like sets in axiomatic set theory. Then there is a decision procedure that will let us decide whether something is a member of the set "
Continue Reading » -
Microservices versus Lean Back in April, I had the good fortune to speak at Craft Conf in lovely Budapest. It's a fantastic conference that I would recommend. During that conference, Randy Shoup talked about his experience migrating from monoliths to microservices at EBay and Google. David, one of the audience members asked an interesting question at the end of Randy's talk. (I'm sorry that I didn't get the full name of the questioner… if you are reading this, please leave a comment to let me know who you are.
Continue Reading » -
Components and Glue There's a well-known architectural style in desktop applications called "Components and Glue". The central idea is that independent components are composed together by a scripting layer. The glue is often implemented in a different or more dynamic language than the components. The C2 wiki's page on ComponentGlue has been stable since 2004, so obviously this is not a new idea. Emacs is one example of this approach.
Continue Reading » -
Faceted Identities I have a rich and multidimensional relationship with Amazon. It started back in 1996 or 1997, when it became the main supplier for my book addiction. As the years went by, I became an "Amazon Affiliate" in a futile attempt to balance out my cash flow with the company. Later, I started using AWS for cloud computing. I also claimed my author page. Let's contemplate the data architecture needed to maintain such a set of relationships.
Continue Reading » -
Inverted Ownership, Part 2 My last post on the subject of inverted ownership felt a bit abstract, so I thought I might illustrate it with a typical scenario. In this first figure, we see a newly-extracted Catalog service, freshly factored out of the old monolithic application. It's part of the company's effort to become more maneuverable. We don't know, or particularly care, what storage model it uses internally. From the outside, it presents an interface that looks like "
Continue Reading » -
The Perils of Semantic Coupling On the subject of maneuverability, many organizations run into trouble when they try to enter new lines of business, create a partnership, or merge with another company. Updating enterprise systems becomes a large cost factor in these business initiatives, sometimes large enough to outweigh the benefits case. This is a terrible irony: our automation provides efficiency, but removes flexibility. If you break down the cost of such changes, you'll find it comes in equal parts from changes to individual systesm and changes to integrations across systems.
Continue Reading » -
Bad Layering If I had to guess, I would say that "Layers" is probably the most commonly applied architecture pattern. And why not? Parfaits have layers, and who doesn't like a parfait? So layers must be good. Like everything else, though, there's a good way and a bad way. The usual Neapolitan stack looks like this: On one of my favorite projects of all, we used more layers because we wanted to further isolate different behaviors.
Continue Reading »