24
loading...
Don’t pass on PaaS
Gartner expects that the PaaS market will double in size between 2018 to 2022 growing at a 26.6 percent rate to about $58 billion by 2022. As per IDG, almost two-thirds of organizations today use PaaS. Post Covid-19, we expect this momentum to continue due to the shift toward remote work.
However, the market is highly fragmented. Gartner notes; “As of 2019, the total PaaS market contains more than 360 vendors, offering more than 550 cloud platform services in 21 categories. The market remains short on standardization, established practices, and sustained leadership.” In this scenario, it is very difficult to choose the right PaaS provider.
PaaS: Under the hood
To get an application running in the cloud, you can spend long hours downloading, compiling, installing, configuring, and connecting all sorts of components— and that’s just on a single virtual server instance. Not only is this costly and time consuming, it takes away from time your team could have spent innovating and improving your application.
To get an application running in the cloud, you can spend long hours downloading, compiling, installing, configuring, and connecting all sorts of components— and that’s just on a single virtual server instance. Not only is this costly and time consuming, it takes away from time your team could have spent innovating and improving your application.
There’s a better way. Technologies between the infrastructure and your application have evolved — the platform layer — making cloud computing easier. Rather than downloading and building all those platform-level technologies on each server instance and then having to repeat the process as you scale, you can go to a simple Web user interface, click a few options, and have your application automatically deployed to a fully provisioned cluster.
As application usage grows, you can add more capacity using the auto scaling capabilities built into your PaaS. When you need to set up increasingly sophisticated architectures with high availability and disaster recovery, you can do this from the same Web interface.
As all the constituent platform components evolve, they are automatically updated for you with no effort required. That is what Platform-as-a-Service (PaaS) is all about.
A PaaS consists of three main components.
First are the software layers your application runs on — “the stack.” These include the various libraries, frameworks, and services the developer uses to build the application, which are present in the runtime environment. The stack consists of the language interpreter or virtual machine (VM), application framework (e.g. Rails, Lithium), HTTP server, load balancer, caching mechanisms, databases, and container orchestration frameworks. A given PaaS may offer several stack combinations to choose from, such as different stacks for different languages or frameworks. The diagram shows a view of a stack based on Kubernetes and containers.
Second is the deployment machinery that packages and deploys containers provisioned with your application stack. This machinery operates directly from your CI/CD pipeline via a Git push, and it gets out of the way once deployment is complete and your application is up and running.
This machinery is itself code, perhaps a combination of scripts and Web services and may use an off-the-shelf technology such as Puppet or Chef. The way this machinery is architected, the particular parameters it exposes, and the functions it makes available to an overlying graphical user interface (GUI) or command line interface (CLI) are important differentiators between a good PaaS and a bad one.
Third is the user interface and the overall user experience (UX). A particular PaaS may provide Web GUI, a CLI, or both. The ordering of the screens, the choices, the logic of how multiple applications and environments are organized and presented—all these factors are make-or-break for the usability of a given PaaS. The goal is to make it easy to change the things you care about and hide the things you don’t care about. The right trade-offs between simplicity and flexibility, constraint and freedom, and opaqueness and transparency are critical.
When you may need a PaaS
Those unfamiliar with PaaS options may ask, “What’s the true benefit of using a Platform as a Service?” They elaborate by saying, “I can install Ruby (or Node.js, PHP, MySQL, PostgreSQL, etc.), deploy my application, and monitor the systems myself!” This is definitely true. Thousands of companies are doing their own DevOps today, and that pattern works for them.
Those unfamiliar with PaaS options may ask, “What’s the true benefit of using a Platform as a Service?” They elaborate by saying, “I can install Ruby (or Node.js, PHP, MySQL, PostgreSQL, etc.), deploy my application, and monitor the systems myself!” This is definitely true. Thousands of companies are doing their own DevOps today, and that pattern works for them.
Where a PaaS can really save you money is when the company doesn’t have the developer resources, in-house expertise, or contractor budget to efficiently manage their production infrastructure.
A PaaS allows a development team of any size to focus on the application instead of the infrastructure, making them more productive and providing more “bang for the buck” with development dollars spent.
Here are 5 basic scenarios when you should consider a PaaS platform to deploy your applications to the cloud.
You Don’t Have In-house DevOps Resources: Setting up platform-level software to run your application is time-consuming and complex. Take a look at this video that compares deploying an application directly to AWS vs using a PaaS. By simplifying, automating, and, in many cases, eliminating the steps associated with setting up the foundation for your application, you can get your application deployed much more quickly in the first place, and you can iterate, adapt, and extend it more rapidly over time. Your developers can focus on development and leave the deployment and management to your PaaS provider.
You Want to Improve Infrastructure Performance: Infrastructure knowledge and expertise is built over time. It's only when you have spent decades deploying applications on Ruby that you have the knowledge to provision the best performing infrastructure stack for Ruby. That's where PaaS providers come in - they have specialized knowledge and expertise about the best database, load balancer, web server, cache etc, to deliver the best infrastructure stack for your application.
You Want to Standardize Infrastructure: With the number of choices available today, it's very difficult to decide what infrastructure choices to make. This has resulted in the creation of bespoke permutations and combinations that work great until vendors’ upgrades require you to keep up with tens or hundreds of configuration changes. Why not let the vendor’s experts make the choices and create standard best-in-class operations that can be managed easily?
You Want to Reduce Infrastructure Costs: The majority of organizations have high levels of idle or underutilized infrastructure. This is because they try to overprovision infrastructure to deliver performance at peak periods. A robust PaaS has inbuilt autoscaling that enables your infrastructure to scale up or down based on demand. This can reduce your infrastructure costs by up to 50 percent over time while providing excellent application performance.
Your Applications Need to Be Managed Round the Clock: A critical consideration for most companies is the type of support an application needs. Is one day of downtime acceptable in your business environment? What about two days? One of the key benefits a good PaaS solution provides is 24x7 monitoring and support so you incur no downtime when there are issues with your application. It's critical here to choose a PaaS partner that provides these benefits.
Reasons to use a PaaS instead of doing it yourself
There are really 3 core benefits investing in a PaaS provides versus doing it yourself.
There are really 3 core benefits investing in a PaaS provides versus doing it yourself.
#1 Increase Agility
Using a PaaS to deploy and run your application enhances your agility and time to market. This is because a PaaS greatly simplifies and accelerates the deployment process. Instead of spending hours or even weeks setting up and configuring a production strength cluster you set it up in a matter of minutes. This improves time to market and helps developers be more productive and focus on what they do best-building apps. You can get your apps to market faster and you can iterate and adapt faster with the same development resources as before.
Eliminating much of the overhead to deploy and manage applications doesn’t just mean you can do certain things faster. It means you don’t have to do certain things at all --. which allows you to be even better at knowing how to do the things that differentiate your business, like building applications with innovative features and exceptional user experiences.
Another challenge of deploying your application on a self-built stack is the sheer number of components that need to be maintained and updated over time. When you need to swap in an update to the app server or the load balancer you may find yourself in a nightmare of reconfiguration. This fear leads many do-it-yourselfers to remain indefinitely on an increasingly outdated stack for fear of rocking the boat. With PaaS, you not only get the best possible stack as of the moment you deploy, you also get a stack that keeps up with you over time, ensuring that your application is always running on the latest and greatest.
#2 Optimize Costs
One of the biggest challenges with provisioning infrastructure to maintain high app performance is knowing how much infrastructure to provision-how many CPUs, RAM, storage etc. that are optimum to guarantee performance at peak periods. Most companies end up over provisioning infrastructure with high levels of idle/underutilized resources. This results in excessive spending on AWS usage, which can be controlled simply by rightsizing the infrastructure. A robust PaaS platform uses intelligent monitoring of application performance in production to rightsize infrastructure. It also autoscales based on demand resulting in higher utilization levels and lower AWS costs.
The other big area where you save is of course the costs of hiring a dedicated person to manage your applications 24x7. The reality here is that such resources are expensive and scarce and you have to ask yourself where the money is better spent. So do the math and see for yourself what's cheaper especially when you factor in the AWS usage savings. All this does not even count the savings in the developer’s time spent on setting up and configuring the application on the cloud as well as ongoing monitoring and management, which can be a 24x7 job for a mission critical app.
There are also less obvious hidden costs, such as the cost of downtime when one of your administrators makes a mistake configuring your application server, and no one can access your Web application for hours. According to a study by Uptime Institute, 70 percent of data center downtime is caused by human error. Consider both the hard costs of downtime, such as lost business and unexpected support costs, and the soft costs, such as idled employees and a tarnished reputation.
#3 Better App Performance
The benefit of economies of scale doesn’t simply stop at getting the same thing for less money. What you actually end up with is something better, for less money. The stack and platform-level technology you would build yourself will almost never be as good as what a top PaaS will provide. Few companies have both the ability to pay and the attractiveness to hire the world’s best platform builders. A PaaS employs specialists who constantly tune, optimize, load-balance, reconfigure, and so on. The result is faster application performance.
The best PaaS vendors embed technologies and techniques in their products to keep availability high enough that they can offer service-level agreements (SLAs) at or above 99.9 percent availability.
One of the key benefits baked into a best in class PaaS platform is autoscaling - scaling up or down based on demand. When building a platform yourself, you basically have three choices: you can optimize for the scale you’re at now, you can optimize for a scale you expect to be at a later date, or you can invest a lot in building your own scaling mechanism. In the first case you risk having to redo your platform and incur downtime when you outgrow your initial set-up. In the second case you will likely waste resources due to overprovisioning. And in the third case, you will likely spend a lot of opportunity cost building something that ends up not nearly as good as what you can get from a PaaS. With a PaaS, on the other hand, you get the benefit of a great scaling mechanism developed by experts over time and in response to the needs of many customers. On top of that, the PaaS scaling mechanism leverages the underlying infrastructure’s elasticity but presents it in an easy-to-use way, abstracting the complexity of the mechanism’s details.
Security showcases another distinct advantage of the PaaS model. With the sheer volume and the diversity of security threats on an upward spiral, protecting against attacks is best left to specialists. A PaaS offering provides continual security updates for individual stack components as they are issued.
Finally, if your application is mission critical and any downtime is unacceptable then outsourcing to a PaaS vendor makes sense. A good PaaS vendor will offer 24x7 support and specialized domain experts who have dealt with hundreds of problems in the same domain as yours. You speak to someone who has access to—may even be sitting next to—some of the leading experts in the community, whether for core Ruby or PHP language stack components or complementary open source projects.
If your core expertise is in developing software not deployment and infrastructure, a PaaS may be the answer to your prayers.
Any PaaS you choose needs to deliver well – not just deliver – in these areas:
• Infrastructure Expertise: Look for a provider with expertise in the language your application is developed in. If you have a PHP application, ensure that they have expertise in PHP infrastructure and can make good platform choices for you.
• Setup & Configuration Time: A good PaaS platform should reduce your setup and configuration time with a preconfigured stack and enable you to push your code directly from Git.
• Horizontal AutoScaling: Look for the ability to scale automatically in response to traffic and usage demands so you don't have to worry about scaling your infrastructure based on planned usage. This will ensure that you don’t need to provision excess capacity and waste valuable dollars on idle infrastructure.
• Support & SLA: If you don't have in house resources then the PaaS provider is your support arm. It's one of the most important choices you have to make so choose a provider with a reputation for robust support. Examine their SLA and response times critically.
• Uptime Guarantee: An uptime guarantee of 99 percent is fairly standard in the business. Ensure that there is no downtime during deployments.
• Redundancy, Failover & Backups: Ensure that the provider takes responsibility for replication, backups, and recovery.as well as keeping your platform up to date with patches and new functionality.
• Security: What kind of security does your PaaS provide? Are you on a private cluster or do you have shared resources? Public clusters are less secure and can be susceptible to noisy neighbor issues where one or more users can hog all the available resources degrading performance.
• Pricing: How well does the pricing scale with usage? One of the common complaints that PaaS users have is the fact that they can become expensive really fast. Ensure that the pricing is scalable and delivers the value vs DIY.
• Setup & Configuration Time: A good PaaS platform should reduce your setup and configuration time with a preconfigured stack and enable you to push your code directly from Git.
• Horizontal AutoScaling: Look for the ability to scale automatically in response to traffic and usage demands so you don't have to worry about scaling your infrastructure based on planned usage. This will ensure that you don’t need to provision excess capacity and waste valuable dollars on idle infrastructure.
• Support & SLA: If you don't have in house resources then the PaaS provider is your support arm. It's one of the most important choices you have to make so choose a provider with a reputation for robust support. Examine their SLA and response times critically.
• Uptime Guarantee: An uptime guarantee of 99 percent is fairly standard in the business. Ensure that there is no downtime during deployments.
• Redundancy, Failover & Backups: Ensure that the provider takes responsibility for replication, backups, and recovery.as well as keeping your platform up to date with patches and new functionality.
• Security: What kind of security does your PaaS provide? Are you on a private cluster or do you have shared resources? Public clusters are less secure and can be susceptible to noisy neighbor issues where one or more users can hog all the available resources degrading performance.
• Pricing: How well does the pricing scale with usage? One of the common complaints that PaaS users have is the fact that they can become expensive really fast. Ensure that the pricing is scalable and delivers the value vs DIY.
When you should not consider a PaaS
While 80 percent of scenarios lend themselves well to a PaaS there may be some situations where it is important to make all the infrastructure decisions yourself. In these cases a PaaS may not be the best solution for you.
While 80 percent of scenarios lend themselves well to a PaaS there may be some situations where it is important to make all the infrastructure decisions yourself. In these cases a PaaS may not be the best solution for you.
In summary, PaaS simplifies application deployment and management, improves agility and time to market and reduces deployment and management costs. If you are a software developer who wants to deploy applications to the cloud, and don't have an in-house DevOps team, a PaaS platform may be the answer.
As seen on ITProPortal.com
24