SaaS-ifying your enterprise application? A quick-and-dirty guide

Lots of people called it SaaS-enablement, some call it SaaS-ification of software. Whatever you call it, more and more enterprises are looking to turn some enterprise application into a SaaS cloud application.

There are several reasons to SaaS-enable an internal application. Enterprises need to expose a software system to their partners and/or customers to better automate the business. Or, they are looking to monetize applications they view as having value to other companies.

Whatever the reasons, there are a few things to consider first. I call this the SaaS-ification reality check:

  1. Can you handle the SaaS? Many enterprises don’t understand what’s needed to manage a SaaS cloud service. You have created in essence a product, and so you need a roadmap of improvements you’re going to make, product management, product marketing, product support, etc. for the SaaS services to be any kind of success. If you’re not willing to invest that much, rethink this venture.
  2. Is the application in good enough shape to be made into a SaaS service? The truth is that when applications and databases are designed for enterprise use, they are typically not built with SaaS in mind. So, they may need to undergo significant refactoring, meaning rewriting significant portions of the application code or restructuring the database.
  3. What’s tenant management? Enterprise applications are written to support many users, but not many tenants. Having many users mean that you’re just standing up one instance of the application and database, even if you have thousands of users connected to that instance. Being multitenant means that you’re running many application instances, in their own application spaces, and each must be separated virtually but allowed to share hardware resources at the same time. This takes additional thinking and understanding because new users require their own tenant space, including their own part of the database, as well as the ability to use hardware resources at the same time as the other tenants.
  4. What about security and liability? If you choose to get into this business, you can’t be half pregnant. So, you need to provide sufficient security so hackers won’t run off with your customers’ data. That bring up another issue: liability. There is risk that your new SaaS service could be hacked, lose data, or have an outage that puts your customers’ business in the red. So, you need to ensure that you’re both protecting your customers and yourself.
  5. What about ops costs? SaaS cloud services are rarely built on the enterprise’s premises but are built and run from a public IaaS cloud. IaaS providers don’t give away their cloud services for free so you can charge for yours. So, make sure to understand the costs of the public cloud that will host your cloud. Typically, it’s much higher than my clients think. Also make sure you understand the all-in ops costs, including the people you need to operate the service, do the troubleshooting, and provide customer service.

Good luck!

Powered by WPeMatico

Capacity alone won’t assure good cloud performance

Many people believe that workloads in the cloud always perform better because public clouds have access to an almost unlimited amount of resources. Although you can provision the resources you need—and even use serverless computing so the allocation of resources is done for you—the fact is that having the right amount of resources is only half the battle.

To get good cloud performance means you have to be proactive in testing for performance, not be reactive and wait for an issue to arrive in production. After all, performance depends on much more than raw capacity.

I strongly encourage testing. If you’re using devops to build and deploy your cloud application workloads, your testing for security, stability, and so on are typically done withcontinuous testing tools as part of the devops process.

But what about performance testing?

Truth be told, performance testing is often an afterthought that typically comes up only when there is a performance problem that the users see and report. Moreover, performance usually becomes an issue when the user loads surpass a certain level, which can be anywhere from 5,000 to 100,0000 concurrent sessions, depending on the application. So you discover a problem only when you’re got high usage. At which point you can’t escape the blame.

An emerging best practice is to build in performance testing into your devops or cloud migration process. This means adding performance tests to the testing mix and look at how the application workload and connected database deals with loads well beyond what you would expect.      

This means looking for a performance testing tool that is compatible with your application, the other devops tools you have, and the target cloud platform where the application is to be deployed. Of course, a “cool tool” itself is not the complete answer; you need testing engineers to design the right set of testing processes in the first place.      

Ironically, although devops itself ( as both a process and tool set) is all about being proactive in terms of testing, most devops processes that I’ve seen don’t do much performance testing, if any at all.     

Withouth that testing, you can’t answer the question “When will my cloud workload hit the performance wall?” Instead, your users find out for you, and you may discover it’s time to look for a new job.         

Powered by WPeMatico

Don’t worry about selecting the ‘wrong’ public cloud

When I speak in public about cloud architecture, I’m often asked a question with no right answer: “Which public cloud should we use?”

Not knowing much about what “we” is, there is no right answer. While I can list the top two players, they may be wrong for “we’s” problem domain when taking into account special issues such as performance requirements, security, and compliance. No matter which public cloud you pick, it will have upsides and downsides, depending on who you work for and your specific needs.

What you need to do to answer that question is simple: Get your requirements in order first before you even start exploring the public cloud market. 

However, enterprises are not likely to do that in the real world. Partnerships are formed in the early stages, and enterprises often have a ton of credits that they can only turn into a single public cloud service brand. Whatever the reason, it’s not stretching the truth to say that most enterprises select a cloud provider based on items other than business and technical requirements.

So, given the reality that your pubic cloud selection very likely will be based on factors other than your requirements, how concerned should you be? The good news is that how you use that cloud makes more of a difference than the cloud brand. 

IaaS clouds, for example, boil down to storage and compute. You can compare cloud services and see that they offer various shiny objects such as machine learning, big data, and internet of things. But if your public cloud supports these basic storage and computer features, you’re usually more than half way home. 

Where cloud project fail is not so much about the cloud selection but about picking the wrong workloads to migrate and not paying attention to security, governance, and other core services. The problem seldom is about the public cloud not living up to expectations or having the appropriate technology.  

So, while picking the optimal public cloud based on requirements is the best practice, that selection won’t determination your success or failure. It’s what you do with that that’s more important that which cloud you pick.

Powered by WPeMatico