The cloud has evolved. Just a few years ago, cloud-based applications were the exception rather than the rule, and on-premises apps were the clear standard for database apps. However, with the numerous advantages of building in or migrating to managed services, the cloud isn’t just a niche anymore. Managed services and cloud VMs are quickly becoming the standard platform rather than just a peripheral option.
The prospect of using cloud services for database applications is especially appealing. Data volume is the most significant factor when building specs for database application hardware or services, and it is also the metric that is almost certain to evolve during the life of the application. Cloud services are far easier to scale up (or down, if needed) than are fixed on-premises resources, which improves the speed and agility with which your database application can adapt to changes.
One of the more common questions I encounter is this: “Is my application a good fit for the cloud?” Since the topic comes up frequently, I’ve put together a set of talking points to help evaluate which applications are well-suited for development in – or migration to – the cloud.
Is Your Database App Ready for the Cloud?
Although far from comprehensive, the list below describes an application or organization that is ready for Platform as a Service (PaaS) managed cloud services.
You are a small company or a startup. I can speak from experience that running a small business or starting a new business of any size means paying careful attention to every expense. Small or new companies usually don’t have the infrastructure to run their own data center, so building an on-premises architecture involves a significant capital expense. Using the cloud to launch your new application or startup lets you pay as you grow without an upfront outlay of cash.
The hardware resource needs will fluctuate. One of the most significant benefits of a cloud infrastructure is its ability to easily adapt to changing workload needs. Consider the case of a payroll application, which will likely see significant spikes when paychecks are cut and reconciled. If you spec your on-premises hardware for those peaks, you’ll have an underutilized (read: overpriced) server for the rest of the times of normal workload. Conversely, a PaaS application can be scaled up to meet those times of high demand, and scaled back to save money during normal operations. This scale up/scale down operation can even be automated. Pay for what you need when you need it without the buyer’s remorse of buying too much (or too little) on-premises hardware.
Data volume is expected to grow steadily. If you’re buying an on-prem server for your application, do you buy for today’s needs or what you expect for tomorrow? If it’s the latter, what if business grows more rapidly than you expect? Buying hardware is costly, but having to upgrade early – or worse, buy replacement hardware – to keep up with growth adds to both the hard costs and the time investment to keep the application running. In a PaaS database, scaling up takes seconds, not weeks or months needed to scale up an on-premises database. You’re also saving money in the interim, since you are paying today for what you actually use today rather than what you think you’ll need tomorrow.
You want enterprise-level service but don’t have the infrastructure to support them. Database applications should be highly available and fault tolerant, but those attributes cost money and time. Database and application servers should be protected by enterprise-grade firewalls, requiring staff members with a specific (and usually expensive) skillset to maintain. Using a PaaS architecture reduces the time you’ll need to spend worrying about availability, recoverability, and security hardware, allowing your staff to focus on the business and technical needs of the database application.
You want to have the latest and greatest. Between new versions, service packs, incremental updates, and patches, keeping on-premises software up-to-date is a huge commitment in itself. With managed cloud services, you’re offloading that process to the vendor, which takes the burden off of your staff while keeping you on the cutting edge of security and functionality updates.
It’s a brand new development project. Don’t get me wrong: it’s never been easier to migrate existing database apps to the cloud, and the number and flexibility of the tools for that task keeps growing. However, for any brand-new development initiative, the simplicity and cost savings of a PaaS architecture makes it the platform to beat.
It’s Not for All Apps
While a managed cloud platform delivers on its promise for most applications, there are some scenarios that are not ideally suited for a PaaS environment:
Applications with extraordinary storage or processing needs. Enterprise-class cloud providers have lots of horsepower for managed databases, but each one has limits on what they can provide for a single customer or database. Those limits are increasing as the technology matures, but still represent a hard ceiling of what can be run on a PaaS database.
Your organization has a slow or unreliable internet connection. Most of us have a choice of high-speed internet providers at work and home, but some rural or underdeveloped areas of the world do not have the same luxury. Cloud-based applications depend on a reliable internet connection. It is still possible to build in a PaaS architecture with less-than-reliable connectivity, but the application logic would have to be carefully written to accommodate this shortcoming.
The application requires a specific version of the database engine. In my last job before I became a consultant, my company had a critical application that required a specific – and very old – version of Microsoft SQL Server. Apparently, the previous attempts to upgrade the database failed because the app was dependent on the features of that specific version of the database engine. Such dependencies are not unheard of, and will limit your ability to migrate those applications to a managed database environment. However, that doesn’t mean you can’t use cloud services; running the database application in a virtual machine in the cloud is an option for cases like this.
The political climate in your org isn’t cloud-friendly. Among the barriers to cloud adoption, this one is the most common. Some organizations have enacted a no-cloud policy, instead opting to keep all data in on-premises storage.
Evaluating Cloud Readiness
Deciding on whether to move to the cloud should be done on an app-by-app basis. But as PaaS capabilities continue to evolve, this platform will become increasingly more attractive as a target for new development and migrations.
Leave a Reply