Intro
One of the fun aspects of board games at times is that of the spinner. That concept in some ways could be at play in your IT Department as Software Models continue to evolve over time.
Back in the early 80s it was easy for software to have what was called Spaghetti Code. This was easy to have happen with constructs like GOTO and GOSUB procedures calling other procedures. This was in the time before OOP… That is my inspiration for Spaghetti Systems which are systems in an Enterprise that have direct point to point connections with each other. Often such network traffic can start to look like Spaghetti as well.
Let me ask you this: has your software systems come full circle back to Spaghetti Systems as you’ve embraced a Microservices Architecture?
Do you have legacy systems, COTS, Cloud, and new systems on premise and some in the cloud? Can anyone in the Enterprise easily and quickly locate where in the system a specific business action happens and everything there is to know about it?
Let’s discuss a solution patterns for all the above, but first lets learn some lessons from the past as to why this is a concern for today.
The Old Days
Monoliths
Introducing the Spaghetti Systems Pattern.
Oh the good old days when all the systems talked to each other directly creating an Enterprise Spaghetti Systems pattern, full of Point-To-Point connections, that required diagrams to understand who talked to who, when, and why, and of course those were never up to date.
ESB
Then came along ESB systems. Suddenly all of the Enterprise Systems could flow to only one location allowing for the mighty Pub/Sub pattern enabaling any system interested in the data flowing by could get it.
Some companies of course jumped all over this and others ended up with a mix of some Point-To-Point and ESB integrations.
API Managers
With any good industry disruption story a whole new system came along called Cloud Computing and the API model was quickly adopted. Soon Enterprises were able to have their own on-premises API Managers as well.
APIs for some made the ESB no longer relevant as the Martin Fowler’s principle of “smart endpoints and dumb pipes” concept started to take off as more and more companies introduced Microservice Architectures.
However the ESB concepts of message translation, manipulation, guaranteed delivery, and so much more shouldn’t be wholesale thrown out. API Manages and ESB can be married up very nicely to enable Open Enterprise capabilities that would have to be written from scratch otherwise.
Now We Have Micro API Gateways and Micro Integrations at the Cells Layer
As Disney’s Hannah Montana used to sing, “You take the best of both worlds”, and this leaves us in the Microservices world with Micro API Gateways and Micro Integrator ESB functionality as provided by WSO2 in API Manager 4.0.
We now have the building blocks for a true modular Cell-Based Architecture (Ref1 & Ref 2) type application pattern where one part of a system can go down, minimizing the impact to other systems. The rest of the minimization comes into play by how you architect your services, running in an highly available stack, and other patterns such as streaming messaging that can be replayed as needed.
Spin Me Around Again
Given the complexity and volume of the Microservices pattern it’s easy for these to become the new Spaghetti Systems of today.
But by learning from the trail blazers of the past, like Netflix, and with a bit of planning you don’t have let that happen!
This video is a oldy but goody on this.
Open Enterprise Micro Rules Of Success
These patterns and systems will probably be added to and updated over time.
1.0
Service Registration
Microservices/Integration Developers will need to be able to register their Micro API Gateway with the Facade API Gateway through the API Service Registry.
2.0
Developer Portal
Developers should have a portal where they can register their application/service to utilize a particular facade API.
Developers should only be able to sign up for the Facade API.
3.0
Documentation Wiki
By keeping your APIs, services, and back-end systems documented in a wiki then all of your Developers, Business People, DevOps, and Architects can know where to locate the “Truth” about your Open Enterprise Services.
No code can be released to production until these have been updated to match.
4.0
Naming Conventions
You should always be able to tell what something is from it’s name.
If the Enterprise Architects haven’t established a Taxonomy naming strategy then it’s time.
5.0
Never Break The Contract
Every time something that an outside service can call needs to change, meaning the contract of that service, then a new version of the API should be created.
NEVER BREAK THE CONTRACT!
6.0
Use Pre-Built Components
If there is a plug-in or connector for that requirement then use it. Only write custom code if absolutely necessary.
At the same time the assembly you do in-house creates the secret sauce for your Enterprise’s success.
7.0
Sniff Out The Spaghetti To Tame The Chaos Beast
If ever there is any confusion around what is available, what is connected to what and where, or any thing else that smells like Spaghetti Code or Spaghetti Servicing, then it is time to refactor and fix it.