We are super excited to introduce our new product BizTalk360 Cloud, a SaaS version of BizTalk360. This is our first footprint in the cloud. As a technology driven company, we are moving towards cloud to get in step with the current trend and technology progress. Microsoft Azure is becoming one of the most powerful platforms in recent days, where it solves infrastructure and service related challenges (IaaS, PaaS, SaaS). In the same way, we thought of introducing the SaaS version of the BizTalk360, where the customer pays only for what they use.
It took a huge effort across the team, from learning Azure technology to shipping the product. I’m very proud to be part of this development phase and pleased to write this blog to share my working experience with this product. Though It is not possible to share the complete experiences through this blog, I have picked some of the important facts that we need to keep an eye on, before starting the new product in SaaS and what are the benefit we can enjoy out of the SaaS Product. I thought this could be valuable for the readers.
- Decoupled architecture
- Utilizing the right services from Azure
- Overhead Cost
After a lot of brainstorming with the PoC, we identified the decoupled architecture as the right choice to develop a SaaS product in Azure. A big enterprise solution like a BizTalk360 will have a lot of components to solve the day to day business problems of the customers. So we should segregate the components in such a manner that it does not depend on any other component or service. Thus any specific changes to a component can be dealt with itself. Whereas in the coupled architectures all the components might have a dependency on other components so it becomes difficult to make changes in the code.
In a SaaS product, we will have a lot of services to deploy the components like app services, cloud service, etc. So if it has the decoupled architecture, it makes easy to do any changes and deploy the component while it is in production or staging. In this case, there is no need to do the full deployment or stop all the services for the minimal level of changes. In BizTalk360 Cloud, we have achieved this by separating the components as Front-End and Back-End or Server side. Our Server side components include Provision Manager (where we create resources for each customer), Payment Manager, Email Manager, and etc. These components are not inter-dependent on each other.
Utilizing the right services from Azure
This is one of the important points to consider while developing a SaaS based product. Since every service will have different types of cost planning based on the level of the service. So we have to choose the right service based on our functional requirements. Let us consider a scenario where four people have to travel from place A to B by a rented vehicle. In this case, obviously, a car should be enough to fit in those four people rather than hiring a full luxurious bus. Similarly, in the case of Azure, there are multiple services that can do the same functions with a different cost so we should identify the resources for our specific need.
For example, we have a bunch of background components in BizTalk360 Cloud. In the initial stages, we were not familiar with Azure resources as this was our first SaaS-based product. We choose the cloud service to host the background components and over a period of time we identified the web job as an another option. Web job is specially designed to do the background tasks independently within the app services. So if you already have an app service, it is better to use this web job and for that, you don’t need to pay extra for it, whereas if you choose the cloud service you have to pay an extra amount. In our case, we decided that the web job was enough for our need.
Per month pricing for cloud service lower plan:
This is the most important capability in Azure. Since all the web applications will face the scalability problem but this can be easily achievable in Azure. Let take some eCommerce application where there will be more service requests during an offer seasons and on normal days they will have fewer service requests when compared to offer season. Here, the user has to physically increase the environment setup during offer seasons and again they have to reduce the setup on normal days. But in Azure, we can easily scale up the environment by just changing the pricing tier. By this way, we can increase the performance of the environment and scale down if needed.
In Azure, all the resources are associated with the specific pricing model so we need to keep an eye on that, when we create resources like virtual machines, etc. In case if you accidently create any resource with high configuration and leave it unnoticed for few days, you will incur a considerable amount of money without using the resource. In our case, we had created two virtual machines with high configuration for demo purpose in Integration 2016, London event and unfortunately we didn’t shut it down for a few days. When we received the monthly invoice we noticed the usage amount was high. After a detailed analysis, we identified that the virtual machines were not shut down and also the configurations were higher than needed for the demo. So be careful with the overhead cost!
Check out our Founder Saravana Kumar’s blog on Moving to the cloud, uncontrolled cost and over budget disasters.
Developing software is an evolving process, once the initial version is launched in the market we need to continuously add new features to the applications. Eventually, the whole idea is whenever there is an update of the product, the customers should get it without any manual upgrade process. In an on-prem application, each time when we release a new version, the customer needs to update their deployment. In this situation, we will have some difficulties to provide support to the user. This will complicate our support activities along with the testing efforts. In the SaaS version, we are not really bothered about this scenario since all the infrastructure is from our end. We can develop the new features and do the deployment whenever we need without disturbing the customers. Just from a click of a refresh, the customer can see the new features.
I hope this blog will useful for developers who are involved in developing a SaaS based application in Azure.