Is your software architecture ready for innovation?
You will come across a lot of these terms when reading up on software architecture, DevOps and best practices when it comes to software development. But what do they mean and how do they impact your infrastructure, development and processes as an ISV?
Wesley Haakman, Intercept
If you look past the the buzz words and look at the very basic principles, then we’re left with two strategies: Loosely coupled and tightly coupled architectures. Even though a lot of articles and advisories focus on loosely coupled architecture, both have their own set of benefits depending on your software and your organizational structure. The software engineering principles behind loosely coupled and tightly coupled architectures is beyond the scope of this article, instead we want to give you something to think about when refactoring your application and help you with building the architecture that will benefit you most.
As an ISV you generally want a achieve at least some of the following:
- Short time to market;
- Minimize risks when release new versions of your software;
- Not bound or limited to specific architectures / languages.
There are multiple ways to achieve this, and choosing the right software architecture is definitely one of them. If you look at modernizing your platform and your application with the help of Microsoft Azure then rehosting (or lift and shift if you will) is by far the most popular first step. Rehosting usually has a minimal impact on your application but you can still start enjoying a subset of benefits that Microsoft Azure offers. But your journey doesn’t end there. If you truly want to make use of all that Azure has to offer then the next step in your cloud adventure will be looking at refactoring or rearchitecting your solution to best fit the new platform you migrated to.
Most ISVs have been in business for multiple years and started out with a traditional solution where everything that is required to perform the tasks at hand is built into that single application, using one language. There are no (or minimal) dependencies outside of the application, changes to a single component or feature will most likely impact other components. Rewriting or adding pieces of code may very well impact the rest of the application in ways we had not expected (cross fingers when deploying and wait for customer feedback). We call this tightly coupled, or sometimes “monolithic”.
So what’s the alternative?
Changing to a completely different architecture is not something that happens overnight. It takes careful planning, probably some technical deep dives with Development and Operations, revisiting your roadmap, reviewing your business processes and thorough testing. But it is worth it. Decoupling your application can be done in many ways and can be achieved over time.
Probably one of the best examples of decoupling is adding a service bus or message que to your application to decouple processes that were previously highly dependent on each other. For example: “Process A” can still deliver its message and continue without having to wait for “Process B” to accept the message (if it’s unavailable), allowing us to perform changes on “Process B” without shutting down the entire application. Or we can scale the instance of “Process A” independently from “Process B” when an higher load is expected. To put this into perspective let’s call Process A “Orders” and Process B “Order Processing”.
In a traditional monolithic architecture if we receive a lot of orders, the performance of our “order system” is dependent on how fast we can process the orders. If our order processing service is unavailable or underperforming, we might miss out on valuable business as new orders cannot be placed.
Now if we would “decouple” our order system and add message queuing, we will achieve a state where the ordering process can always “offload” it’s messages, regardless of the availability or performance of our processing instance. We can even scale our different services up or down depending on the expected load without impacting other components. Or update “Order Processing” with better and faster code without having to update the entire application.
In general, this is what we mean when we talk about “loosely coupled architectures“ or “Micro Services”. We want multiple services, processing independently and be (to some extend) unaware of each other. In fact, all we want is that each service has a standard interface that other services can use to communicate with it. For example HTTP REST API’s. Regardless of the language the service is written in, the location it’s deployed to or the amount of instances (scale) used for each service, as long as the interfaces remain the same your application will function.
Of course decoupling your application is so much more than this but the principles remain. It will bring you flexibility, scalability and more control over your architecture.
Get loose on Azure
So you decided to go loosely coupled and use Azure. Microsoft Azure provides you with a very extensive set of features that will help you decouple your software architecture, mostly in the “serverless” area. The principles behind the serverless architecture on Azure is that you are no longer focusing on infrastructure, the platform or computability. You are focusing on development, providing your customer with new features and you are truly billed based on consumption. There are many, many features on Azure that will help you. From our experience we want to highlight the platforms we come across mostly when helping ISVs decouple their software.
You could for instance decide to offload some processing to Azure Functions which comes with off the shelf HTTP Triggers and endpoints so all you need to focus on is the actual processing. You will only be billed based on consumption. If there is nothing to be processed; no costs.
We also have the ability to use Logic apps and interface with popular SaaS applications using the out-of-the-box connectors or offload some intelligence to Cognitive Services. And.. completely configurable through a graphical user interface, no code required.
Azure Service Bus & Event Grid
One of the easiest ways to decouple is starting with message queuing or event triggers. Azure Service Bus and Event Grid will help you with just that. Where as Azure Service Bus will provide the functionally as mentioned earlier in this article (reliable message queuing). Event Grid will help you route events from different sources to multiple destinations and activate triggers based on what it is receiving. In many architecture we see these platforms as the “center” for communication.
Databases are also available within the serverless world on Azure. Most are already familiar with the Platform as a Service offering “Azure SQL”. Even though Azure SQL has it’s own use cases and is definitely here to stay, a good alternative (if it fits your model) is Azure CosmosDB which is a highly scalable, low latency storage offering that will fit most applications.
Even though implementing Cognitive Services is a different story all together and in most cases will require some understanding of Artificial Intelligence and Machine Learning; features like text analysis (language, sentiment), speech recognition and search API’s are available out of the box through API’s and require minimal effort to implement.
Benefits for ISVs
As an ISV, going loosely coupled will help you in different ways. When you are no longer dependent on one monolithic application and your maintenance / update windows with customer will no longer be as “exciting”. Instead you can focus more on development, adding rich features to your offering and add value to your product in an easier, more controllable way. Multiple teams can work on different services (remember to decide on a standard way of communication!) without interfering with each other. You can update different components of your software architecture without impact other services, allowing for a shorter time-to-market.
Secondly you can now scale different parts of your application when required, only increasing costs for that one service (for instance “order processing”). If you also decide to go “serverless”, this will greatly impact the financial picture as you are only billed for actual consumption.
Additionally, you will give your developers more freedom, allowing them to write in whatever language is best suited for the functionally at hand. But do try to limit this to some extend to prevent an explosive growth of different frameworks.
Does this mean that tightly coupled or monolithic architectures are dead? No, it really depends on the complexity of your software, your business goals and scalability requirements. In general we do see that the benefits of decoupling your application are worth the investment.