Develpreneur: Become a Better Developer and Entrepreneur

The series switches gears to look at anti-patterns.  We start with the mother of all anti-patterns, architecture by implication.  Any time we have a pattern that includes assumptions, success is a challenge.  Looking ahead, the next several episodes will explore familiar anti-pattern names.  We will find that many coding anti-patterns can also be applied to architecture.  Likewise, these are ways to approach enterprise solutions. Architecture By Implication Defined This anti-pattern is wrong in the implication part of it.  Any architecture that involves implications and undocumented features is an anti-pattern.  The core challenge is that pieces of our architecture are commonly known.  That familiarity breeds a sense of "we all know this."  However, it is a dangerous assumption to make. Our experience and understanding of a pattern or approach are not always the same as our teammates.  Thus, we may think everyone is on the "same page" when multiple views are involved.  That can be either the situation or the approach we are taking. The Anti-Pattern In Action Lack of documentation and minimal design often lead to this anti-pattern.  It also occurs more frequently in larger teams than in smaller ones.  A group of two or three people is more likely to be synchronized on the solution approach.  Likewise, communication is more manageable and better with fewer people involved.  Once the team grows to multiple teams or groups, documentation becomes critical.  It is the first step in ensuring everyone has the same understanding of the approach. A vital factor of this anti-pattern is point-of-view.  When different groups look at a solution, they may have different views of its construction.  That leads to gaps, blind spots, and incorrect assumptions.  For example, look at the classic Volkswagon Beetle.  It is easy to assume the engine is in the front of the car.  However, it is in the rear.  Think of how many problems can be caused by such an incorrect assumption. Avoiding The Anti-Pattern This anti-pattern boils down to communication.  We avoid it by spending time designing and documenting our architectural approach.  Next, share those documents with all of the team members.  The result is every member can see what the plan is.  Finally, they are confident that the rest of the team has the same understanding. This solution is simple.  However, we will see that many anti-patterns are easily avoided similarly.

We wrap up our patterns focus with the space-based pattern.  This is also known as cloud architecture.  We will see how this approach allows us to break out the solution into components suited for scaling.  We solve the problem of scalability in architecture instead of tools. The Space-Based Pattern Defined We have often seen layers in our architecture discussions.  Similarly, this pattern breaks out each layer into many workers.  Therefore, it is described as a collection of grids.  First, we have processing units that do the bulk of the work.  We then have a virtual middleware composed of messaging, data, processing grids, and a deployment manager. Applying The Pattern We see in the above list of components that each step of functionality in an application is broken out.  However, the critical piece is the processing unit.  There is often a bottleneck somewhere among the layers.  We avoid that by replicating the entire solution across processing units in this approach.  Then we can laterally scale out the solution by adding more units. This solution may seem obvious and straightforward.  However, keeping those processing units in sync requires overhead.  We are replicating data and code.  Thus, breaking the reliance on a single database or store.  That often is the limiting factor that we are now getting away from. Challenges Synchronizing the components is the hardest part of the space-based pattern.  Each piece needs to fulfill the requirements for the solution and "know" the current state.  Of course, a stateless solution makes this a breeze.  However, that would essentially be a microservices architecture.  This approach needs more information to provide the necessary services.  Nevertheless, this also is a solution that tends to be perfect for high availability.  When you have units shut down, you launch more to recover from those downed components.

We come to one of the best patterns for breaking a big problem down into bite-sized pieces.  The microservices architecture pattern is a perfect fit.  The objective is to farm out work to one or more services that are small and well-defined.  This pattern is one that has grown in popularity and is often seen in Cloud solutions. The Microservices Architecture Pattern Defined The architecture is another one that has three primary components.  There are client requests, an interface layer, and service components.  Likewise, the microservices architecture is another distributed pattern that allows the solution to grow as needed. In general, requests are directed to services via the interface layer.  That layer also can bundle or roll up responses so any request becomes a series of microservice requests.  For example, we can split up reading from a file into a service that gets data, another that parses the data, another that does validation or computations.  Finally, one that formats the results for output.  We keep the services as small units of work that are well-defined and have a large number of uses. Applying The Pattern As noted, this is another distributed pattern.  We take the problem and split it into small units of work.  In this case, the small is micro and gives us the name.  We gain the benefit of having a worker that is able to solve a general problem.  Thus, we can re-use the workers and not only the source code.  That can be a huge productivity increase.  Likewise, we can create tight and high-quality workers that provide a foundation that rarely changes or needs updates. Challenges We can overdo this pattern.  It is like many where we want to use bricks for our solution, not sand.  There are problems that do not need to be reduced to smaller parts.  Once we hit that level, create the service and declare victory.  However, we need to be cognizant of the resources required for our services and ensure they do not rise above the level of "micro."  We want a solution of small steps, but not too small.

The focus of this episode on software architecture patterns is the microkernel pattern.  It is a common way to build on core technology without the need for future design.  Once the plugin interface is defined, the sky is the limit for enhancements and upgrades.  You do all of this without impacting that core. The Microkernel Pattern Defined This approach starts with a core piece of functionality.  Next, other components are added to it.  We see this pattern utilized in many cloud products and commercial software.  The core can be protected, and then plugins farmed out.  Also, customers can purchase the core and then plugins a la carte.  In a technical sense, the core provides shared functionality across the system.  The plugins allow us to upgrade or enhance the core in a focused way.  The core is not touched with this pattern and can provide a stable foundation.  The enhancements are plugged in and thus not likely to impact the overall system negatively.  We define the interface that allows for the plugin, and then it is up to future developers to expand on the solution.  The plugin interface is often thin and straightforward, leaving the plugins nearly stand-alone modules.  Likewise, we can split a more extensive solution into smaller pieces that are easier to manage. Applying The Pattern The opportunities are endless for this pattern.  We can solve small problems with hooks included for plugins.  Likewise, we can build enterprise systems that allow for future expansion.  Of course, there is an overhead cost of a plugin interface.  However, that can often be kept to a minimum when limited data needs to be shared.  Finally, there are many examples of this pattern out in the wild, and a search can find excellent reference projects. Challenges The best use of this pattern is when you have a well-defined core and multiple implementations of some features.  Note that the plugins can be numerous and different in the service they provide. For example, the various ports on the back of a desktop computer provide different plugin options.  We can leave some of our implementation details for the future and focus on what we have in front of us today.  The microkernel architecture allows for "plug-and-play" options and testing partial solutions.  That adds up to excellent benefits.

We continue our season of software architecture patterns and more by reviewing the interpreter pattern.  This one may seem familiar.  It has been discussed in other areas of software development.  However, it is worth refreshing our memory on this helpful solution. The Interpreter Pattern Defined The way this works is to start from a client, and given a context; we receive an expression.  That may be a very simple or complex series of "sentences."  Next, the expression is broken down into parts that are individually interpreted.  Finally, the combined results are sent back.  That gives us yet another pattern that involves breaking the big problem down into smaller pieces.  Thus, it is easier to solve. Applying The Pattern There are many opportunities for us to create a language in software and then use an interpreter.  Likewise, every computer science student has spent some time with these sorts of problems.  Of course, every computer language has this pattern implemented in some way.  While the interpreter pattern may seem difficult to apply, it has potential in many areas.  Therefore, it is worth considering as you design your approach.  As you will see, it is another way to chop up a big problem into more manageable bites. Challenges This pattern is based on splitting up the work (interpretation) into stand-alone steps that can be mixed and matched as needed.  The challenge is to avoid interdependencies wherever possible.  The less each unit of work links to others, the easier it is to build and re-use the solution.  There is also the problem of walking through a sentence or complex expression and breaking it into component parts. For example, think of diagraming a sentence.  It is not always a natural way to think about a request.  However, you can build from simple expressions up to complex ones.  Next, use testing to confirm you are on the right track.  Thus, the solution often ends up much easier to maintain than a holistic approach.  The focus is on components instead of the permutations of expressions.

The blackboard pattern is arguably the least known among our first group.  This is a pattern that is not common because it is best used with some specialized tasks.  However, you may be familiar with it if you work in speech recognition, vehicle tracking, sonar signals interpretation, or similar open-ended forms of searching and matching. The Blackboard Pattern Defined Three appears to be the magic number for parts of an architectural pattern.  Likewise, this pattern again has three concepts that make it up.  There is the blackboard, the knowledge source, and the control.  These parts work together to match data to a solution. The Blackboard pattern uses the idea of a blackboard as a place to hold global data.  We can inspect or update the blackboard.  A knowledge source can update the blackboard, and we can have multiples of these.  Then, the control works with multiple sources and interacts with the sources and the blackboard.  The control effectively loops through sources looking for a solution and then posts that solution once found.  Thus, this approach allows us to quickly match known solutions or expand available solutions when a new one is needed. Challenges We can simplify the blackboard pattern to a form of complex pattern matching.  We are looking through data and determining whether it is new or matches a known solution.  Therefore, the whole pattern is rather loose in its definition.  We can use this to group things like socks of the same color shades or audio of various musical instruments.  Thus, we are doing complex work, typically in the control component.  Likewise, we have an open-ended solution set that can sometimes take substantial time to build out.  The pattern is simple in design.  However, the implementation can be very complex.

The Model-View-Controller pattern is one that is common and often seen in frameworks.  It provides us with a nice place to "hang" our code. The Model-View-Controller Pattern Defined We have another pattern that contains three parts.  In this case, we have the model, the view, and the controller.  These each has an area of functionality they contain and are intended to act without regard to the other areas.  The effect is not unlike other patterns that divide and delegate functionality.  The MVC pattern divides by interaction with a user.  We have the View that displays information to the user.  Then, we have the Controller that handles input.  Finally, we have the Model that addresses the core functionality and data. Clearly Defined Boundaries The power of this pattern is that we can focus on the work at hand.  We trust that the other areas will be properly designed and implemented.  This approach is useful in many cases.  However, it becomes almost invaluable in modern software solutions where there are numerous specialists involved in a given solution and as many technologies.  We also get to detach application logic from the interactions.  That allows us to have multiple delivery devices for our application and focus on each.  This pattern is perfect for the solutions where you need a web interface, and a mobile device, and a watch.  We also are free to add devices in the future without having to touch the core functionality.  Not only is this valuable for saving implementation time, it allows us to provide major updates without risk of breaking the core code.  We also reduce the regression test load for our changes and can focus those on the updated areas. Challenges The model-view-controller pattern suffers from many of the weaknesses we see in other delegation patterns.  The design and implementation must be done with the intention of placing code in the correct area.  It is not uncommon to see core logic in the view or the controller.  Likewise, the code to generate the view needs to be completely separate from the controller.  Overlap of code across the layers can break the entire pattern and render it useless for our purposes.

We often see the Event Bus architectural pattern in notification frameworks and Android development.  This approach provides us with a way to have a news feed mechanism across clients and processes. The Event Bus Pattern Defined There are three main players in this event bus pattern.  The players are the sources, the bus, and the listeners.  Within the bus, there are channels.  In this pattern, the listeners subscribe to a channel or channels.  Likewise, the sources post messages to one or more of these.  That allows sources to note something happened.  Likewise, any subscribers will see it.  Note that this is a one-way architecture.  Listeners will not communicate directly with sources.  However, you could have a return bus that listeners are sources for.  Nevertheless, the goal is for the listeners and sources to act without knowledge of each other.  Thus, the items on the channel are "post and forget" messages. Need To Know Basis The problem this pattern solves is when an action is performed or requested, and it needs to be addressed.  However, not right away, and there may be multiple players involved.  We use this approach to queue up those items.  Then, they can be acted on in many ways and many times.  While the peer-to-peer pattern could potentially solve this problem, it is not recommended.  The result can become too complex and place too high a burden on the services involved to maintain those relationships.  Remember that multiple sources can post to a channel, and multiple listeners can be linked to each channel.  This solution allows us to simplify the number of connections in a many-to-many relationship. Challenges This pattern can be over-burdened by listeners or sources.  Likewise, the bus can get filled up.  Therefore, we need to make sure we expire messages on the bus.  Also, we must not allow for too many actors on a channel.  Finally, we need to think about what is put on the bus in terms of size.  While you can have large message sizes, that can cause problems as the network gets filled with too many actors.  The data can be expensive to move around.  Thus, like most patterns, we need to be intentional in our design.  So, we do not put an undue burden on the system.

This episode digs into the peer-to-peer software architecture pattern.  It is common among file-sharing and crypto networks.  Likewise, the pattern is not too complicated.  However, it is robust and secure as we have tightly defined communication paths.  We also have every node playing the role of both client and server. The Peer-To-Peer Pattern Defined The description of peer-to-peer is even less complex than client-server.  We have two nodes with a bi-directional link between them.  Each node can serve as a client or as a server.  Therefore, we also see this at times when we want to keep two machines synchronized for load balance and fail-over purposes.  The network can expand to any number of nodes.  However, each node connects to another as both a client and a server, so direct communication is always available. On The Same Page While there are many benefits for a peer-to-peer network, the primary focus is keeping each node current with data.  That data may be a file, a list of transactions, or even authorization lists.  Any given node may interact with numerous other nodes, but those interactions will always go both ways.  Thus, an update on node A may be broadcast to nodes B through Z, and then an update on Z may go out to A through Y.  Challenges The goal of peer-to-peer is to keep things synchronized.  That means we want to update the other nodes when we have a change request.  The work required to do those updates can flood the network and need to be managed.  An old example is early network games like Doom that sent out too many updates to the network.  You could crash the network as timeouts ran rampant across the nodes, and they tried to resend that data.  There are patterns for doing such notifications that we will discuss at a later date.

The broker pattern may seem very similar to some others we have examined.  However, it is more about distributed systems than balancing traffic.  The pipe-filter and master-slave patterns provide single path processing.  This pattern sends the requests down different paths based on the request itself. The Broker Pattern Defined A broker pattern is a sort of tree structure.  We start with a client that makes a request to the broker.  The broker assesses that request and then sends it to a server that can handle the request.  Note that the selected server is not a candidate for load purposes as much as its services.  The broker queries servers (or server report when they register) for services provided.  This pattern allows us to have a flexible system for requests. Stepwise Expansion of Services The strength of a broker is that it can accept any request.  However, that does not mean it will process every request.  If there is no server that can handle the request, then an error or service not available response is sent.  That allows servers to go down and the broker to still take requests somehow, or we can add services to expand what the broker can do. We can also version our services to expand individually while still supporting older requests.  For example, the request to get a customer record may go to different servers depending on whether it is a "1.0" customer record or a "2.0" record.  Clients will always be able to make requests and might even retry them to wait for a server to become available. Challenges The broker pattern is sort of like a yes-man.  It will take any request and pass it on or say the service is not defined.  It is not going to tell you much more about the request.  A malformed request may never be supported while not flagged as such.  This pattern can create a massive backlog of enhancements because they can often be seen as easily tacked on.  There is a need to reign in the scope of new requests or at least to plan out the roadmap for them.  Otherwise, the broker may get flooded with requests for non-existent services that impact the performance of those it is meant to serve.