Develpreneur: Become a Better Developer and Entrepreneur

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.

The pipe-filter architectural pattern is very common and used to process data.  It is flexible and scalable.  This pattern has existed in other areas.  However, it is the perfect solution for software problems that need steps or filters. The Pipe-Filter Pattern Defined Think of a start and an endpoint.  Data has to go from beginning to end, and work will be done on it along the way.  The work done is the filters, and we can place any number of filters along the journey.  Each one is stand-alone in a sense as it takes in data, does the work, and then spits it out on the other end.  We can change countless steps like this together as one might do with Lego blocks. Each Step A Island One of the best ways to create a solution that is easy to maintain and scalable is to take well-defined steps that can easily be swapped out.  We can even add steps that load balance or provide other performance enhancements between them.  That is the strength of the pipe-filter pattern.  We can add, remove, and update filters with ease without rebuilding the system. We have well-defined and consistent inputs and outputs when each step takes data in, does the processing, and then spits it out.  Those same inputs and outputs from step to step make each filter interchangeable.  Likewise, we can start simple with a single filter, test it, and then move to a more complex filter series.  Even better, we can always reduce the solution to a single filter and validate it. Challenges The pipe-filter pattern has drawbacks related to the strengths.  For example, there may be pre-requisites in a solution that limit interchangeability.  Likewise, a bunch of filters can conflict or reduce performance.  Therefore, we need to be wise in our design and not fall back on adding more filters.  Any solution can be over-architected.  Thus, be intentional in designing both the filters and the flow.  A good design does the proper amount of work at each step.  That work also does not require assumptions about the data it is processing.

We switch gears in this episode and look at a pattern for getting work done.  The master-slave pattern can be confused with the client-server.  However, they are very different.  The main difference is how the work flows through the system. The Master-Slave Pattern Defined This pattern is a way to get large jobs done.  In contrast, the client-server pattern focuses on multiple users and requests.  The master-slave pattern provides an example of delegating work within a system. The requests come into the master.  Then, the master splits up the work into pieces that are farmed out to the slaves.  When a slave completes the work, the results are sent back to the master.  The master then puts together the results and provides the result for the request.  The job done may be computational, third-party requests, or cross multiple persistence engines. Share The Load The strength of this pattern is the ability for a request to be shared across resources.  However, note that this does not come for free.  Additional work is done to split up the task and merge the results.  That alone can be resource-intensive based on the job.  Therefore, we should only use this pattern with large jobs that have well-defined ways to split them up. An example is processing a set of data.  Each item within the collection can be shipped off to a slave process and then results returned.  Thus, the work is broken down per item, and we can spread the work across the slaves available.  Likewise, there are types of work within a request that make for good lines to split it up.  For example, there may be data manipulation required, storage retrieval, and computations to be done.  Again, these chunks of work can be sent to slaves that are best suited for each type of work. Different Patterns and Different Goals You may look at the prior paragraph and think we described a layered pattern.  That, again, is a different focus on how the request flows through the system.  This pattern is a single large request.  The layered pattern handles multiple requests and has a focus on the steps required for any request, not breaking down large pieces of work. Challenges The master-slave pattern is not a good fit for many tasks.  There will be problems breaking the effort into smaller pieces, or the request may be small enough that it does not need to be split.  Remember that we have an overhead in splitting the work and merging results.  That cost can exponentially increase the time and resources for a task if not executed properly.

The discussion of patterns sort of goes backwards this episode.  First, we look at the client-server pattern.  It is an older and well-established pattern.  However, it is not suited to modern solutions.  This approach harkens back to the old days of mainframes and massive servers that were shared resources for application users. The Client-Server Pattern Defined This pattern is the simplest version of a layered pattern.  There is the front-end client and the backend server.  Unlike the layered approach, the client-server pattern is more focused on resources.  This approach embraces the idea of a central server that clients connect to for sharing data.  It also gives a central point (the server) to scale the application.  Thus, you can think of this as a hub and spokes architecture with the server as the hub. Reduced Integration Any developer that has spent time building applications will tell you that less integration leads to more straightforward solutions.  There are shortcuts and simplified approaches available when you have a single tier.  The application can do things without relying on how others do something or what they expect.  The client-server pattern gives us the best of both worlds.  We can work almost in a silo on the client and only offload what we must (the data) for our solution.  Even single-user applications sometimes use this pattern.  It allows for distributed processing and storage, which is particularly useful as the data size grows. Tried and True There are thousands of client-server applications that have been written over the last fifty or so years.  That means there is a lot of shared knowledge about how best to adopt this pattern.  In addition, we have books and sites that can provide deep knowledge about the caveats and potholes that occur.  That gives us confidence in a successful implementation. Challenges We mentioned at the start that this is a pattern that struggles to provide modern solutions.  Yes, it is possible for mobile and web applications.  However, the layer pattern works much better due to the number of connections often required to the datastore.  A connection to a web server is far easier and cheaper to support than a database connection.  This pattern also makes it hard to cache data and deliver it properly.  That being said, this is a pattern that can serve most of your needs even if it is not the most scalable solution.

We start this season of the podcast with an overview or review of software architecture patterns and anti-patterns.  This season will explore several of these, so it only makes sense to give ourselves a solid foundation for discussion.  We have talked often about these, but a refresher never hurts. Software Architecture Patterns Defined As we often do, we can start with a definition from Wikipedia. An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context.[1] The architectural patterns address various issues in software engineering, such as computer hardware performance limitations, high availability and minimization of a business risk. Some architectural patterns have been implemented within software frameworks. Note that multiple considerations go into software architecture patterns.  We should all know that software development is more than writing code.  These factors are some of those items we need to be aware of. The Value of Patterns There is a lot of value in reviewing patterns and anti-patterns no matter what project we attempt.  In effect, we are reviewing those that have gone before us and what was successful or problematic.  Thus, we can learn from them and improve our odds of success.  That is what patterns provide for us.  Much like other patterns, there is a general approach to a problem lined out for us to adopt.  As with all patterns, these are not the complete solution.  Instead, think of these as guidelines to help you craft your solution to your unique problem or situation more quickly.  We can avoid starting from scratch with these tools to guide us. Frameworks and Patterns You will see that many of the software architecture patterns we review show up in software frameworks.  That is an example of the value these bring.  They provide a foundation for your code that makes it easier to communicate among modules and interact with other systems.  Architecture is often a set of guidelines and hooks for a solution.  Therefore, this is a perfect area for patterns to emerge and be utilized.  When you do this, you will find your team more productive, and higher quality results are an outcome.

No Sprint is complete unless it includes a retrospective and a review.  We need to examine what we accomplished and how we got here.  Those same considerations are important to make a part of our personal lives.  A personal retrospective and review are well-suited for natural pauses in our lives, such as Holidays or a vacation.  The new year is also right around the corner.  A resolution based on our desires rather than avoiding bad things is more likely to succeed. An Agile Year-End A sprint in the world of Agile methodologies includes a review and a retrospective.  The first is where we "show-off" or examine what was completed.  The latter is where we look for ways to improve, either by doing more good or less harm. Then, we can apply these to our results from the past year.  The idea of a sprint is that we set goals, attempt to achieve them, evaluate, adjust, and repeat.  All of those steps are excellent for our personal goals. The Personal Retrospective The essential factor of a retrospective is to find ways to improve.  In our life, we need to define what that looks like.  We can aim to be happier, less stressed, healthier, wiser, make more money, or all of the above.  With these goals in mind, we can perform a personal retrospective.  I recommend an hour or two at least to list out what went well last year, what went off the rails, and then changes you can make next year.  The above may seem like an over-architected solution.  However, it is not.  That time spent will help you walk through your entire year.  It will help to have a calendar or similar tool that can refresh your mind about things done, attempted, and achieved. More Or Less? The best thing to spark this process is a list of your goals from the prior year.  If you do not, then make one for the year ahead.  A good list of objectives and achievements provides you a perfect metric for what you did right or where you stumbled.  These form the basis for change in the year ahead.  While doing this exercise at the end of the year is not critical, it is good to do it when you have some time away from the grind.  Allow yourself to dream a bit of what better days would look like.  Then you can line up some goals to get to those better days.

It is the time of year when we wind down a little bit.  This is when it is essential to reconnect and maybe even take a true vacation. Finally, we can get away from work, emails, and phone calls long enough to enjoy life a little. A True Vacation Recharges You We all have energy levels that ebb and flow.  Likewise, they also tend to decrease over time when we do not incorporate enough rest.  Therefore, we sometimes need more extended rest periods, and a good night of sleep is not enough.  That is where a vacation comes in.  We can unplug, recharge, and find meaningful rest and recovery during a true vacation. The Pseudo Vacation The more typical approach to time off in the modern world is a pseudo vacation.  That is where you technically are off of work but still check emails and may even attend some meetings.  While it is helpful to have those partial days, it will not give you the chance to recharge completely.  You will still have concerns, some work-related stress, and a calendar to keep an eye on.  There is a big difference when you wake up in the morning and have nothing on your plate that has to be done.  That is the mark of a true vacation. Full Of Activity Or None Note that we can do things during our vacation.  We just want to avoid work-related items. So go ahead and plan that trip to Disney World that is full of fun and entertainment.  Just make sure you avoid scheduling it around some meetings and emails to return.