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 »maneuverability
-
Microservices versus Lean -
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 » -
Inverted Ownership One of the sources of semantic coupling has to do with identifiers, and especially with synthetic identifiers. Most identifiers are just alphanumeric strings. Systems share those identifiers to ensure that both sides of an interface agree on the entity or entities they are manipulating. In the move to services, there is an unfortunate tendency to build in a dependency on an ambient space of identifiers. This limits your organization's maneuverability.
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 » -
Maneuverability Agile development works best at team scale. When a team can self-organize, refine their methods, build the toolchain, and modify adapt it to their needs, they will execute effectively. We should be happy to achieve that! I worry when we try to force-fit the same techniques at larger scales. At the scale of a whole organization, we need to look at the qualities we want to have. (We can't necessarily produce those qualities directly, but we can create the conditions that allow them to emerge.
Continue Reading »