How to Succeed at SaaS – Part 2
In Part 1 of this series, I discussed what I believe are best practices to help you ensure your next SaaS based application is a success. I emphasized security as SaaS solutions inherit all the risks associated with the internet, such as unauthorized access attempts, unpredictable performance, and more.
In Part 2, I discuss how to qualify if a new application is an ideal candidate for SaaS. I will also discuss how to qualify if an existing or a legacy application can be converted to SaaS and how.
While the easiest model for implementing SaaS is when designing new applications, the list of requirements below will guide you in determining if your application will be a good candidate for SaaS or not.
What requirements are ideal for SaaS?
- Need for multitenancy with single multitenant database or multiple databases
- Remote access via web, mobile or RESTful APIs
- Need for elasticity as it relates to processing power, throughput, storage capacity, etc.
- Need to control or predict cost of support and maintenance
- High availability and robustness, including 24×7 access with high up-times
- Leverage other SaaS services such as Databases, Message Buses, Monitoring, etc.
- Flexible and dynamic configuration
- Compatible with the 3rd party SaaS application framework
- Network data packets are small
What requirements are not ideal for SaaS?
- Tightly coupled integration with internal systems unless you expose functionality via RESTful API’s
- Limited to no experience managing cloud-based solutions unless you use a 3rd party SaaS framework
- Dependencies outside the SaaS environment such as storage, ETLs, etc.
- Special hardware requirements such as a very high number of cores or CPUs, special key fobs, extremely high memory requirements, specialized hardware, etc.
- The application transfers very large amount of information via the network
If you are considering converting an existing application or a legacy application into SaaS, also consider and evaluate the application’s current design to understand its fit into the SaaS model. The following application architecture categories will need to be carefully evaluated:
1. The application security
- Is it tied to security directory services such as Kerberos, LDAP or others?
- Does the application use a secured data transfer mechanism?
2. The operating system(s)
- Is the application running on a Windows, UNIX, Linux or other operating system?
- What version of the operating system is the application using?
- Will an upgrade of the operating system impact the application?
3. The hardware
- How much memory does the application require?
- How many CPU’s or CPU cores does the application require?
- How much storage does the application require?
- Does the application use any specialized key fobs or special hardware?
- Does the application require to run in a clustered configuration?
4. The database
- Does the application use a mainstream database such as Microsoft SQL Server, Oracle, MySQL, PostgreSQL, etc.?
- Does the application use a specialized database such as a NoSQL database or a document database?
5. The network
- Does the application require a high amount of network bandwidth?
- Does the application require a specialized network protocol other than TCP/IP?
- Does the application use a thick or thin client?
6. The performance and availability
- Does the application require a specific performance SLA?
- Does the application require a specific availability SLA?
- Does the application have in place a disaster recovery plan?
The outcome of the application architecture evaluation from the above categories will determine if your existing or legacy application is a good candidate to be migrated into a SaaS model. It is possible that one or more of your application requirements may not be adequate for a SaaS model. This should not discourage you from moving forward with your efforts. At this point, your options will be to modify or customize your application to mitigate any requirement which are not SaaS friendly.
During your SaaS journey, just remember that the SaaS model is all about simplification. Simplification of architecture, design, support and maintenance. If you have any limiting factors such as specialized hardware needs, very high memory demands, high number of CPU’s or CPU cores, analyze that specific functionality and see if you can optimize the application to become SaaS friendly. Of course, this option only applies if you have the application source code.
There are risks involved with moving existing or legacy applications to a SaaS model. As I explained in Part 1, SaaS applications have security built in to their framework. In many cases, existing and legacy applications don’t have the level of security paranoia needed to survive as SaaS. I recommend performing a thorough security assessment of your application and map out its strengths and weaknesses as it relates to security. This way you will have a full risk assessment to help you make an informed decision as whether moving to a SaaS model makes sense for your application.
Lastly, if you don’t have the source code or you are not able to migrate your application into a SaaS model for other reasons, you can still take advantage of the cloud. If it is a 3rd party application, see if your vendor can help you “lift and shift” your application to the cloud, or if they already have a SaaS flavor of the application. Be aware that some vendor software agreements do not allow you to simply move an application to the cloud (although this is not the SaaS model we are discussing). Therefore, always check with your vendor first. They may save you time and money with options they may already have.
Emilio Chemali, Director of Business Intelligence & Analytics, MRE Consulting, Ltd.
Emilio is a technology subject matter expert, respected thought leader and CIO100 Award Winner. With over 18 years of experience, Emilio has helped clients in multiple industries create business value through Business Intelligence, Data Analytics, DataOps, DevOps, IoT, Application Integration, Enterprise Mobility, Enterprise Architecture, Software Development, Infrastructure Management, Cloud Strategies, Server Virtualization, and Application Performance Tuning initiatives.
Click the link below to download the PDF version. | Click here to read other MRE Insights.