What is PaaS?

https://azure.microsoft.com/en-in/overview/what-is-paas/

Fotango, a London-based company owned by Canon Europe launched the world's first[5] public
platform as a service known as "Zimki". It was developed in 2005

Platform as a service (PaaS) is a complete development and deployment environment in the cloud,
with resources that enable you to deliver everything from simple cloud-based apps to sophisticated,
cloud-enabled enterprise applications. You purchase the resources you need from a cloud service
provider on a pay-as-you-go basis and access them over a secure Internet connection.

Like IaaS, PaaS includes infrastructure—servers, storage and networking—but also middleware,
development tools, business intelligence (BI) services, database management systems and more.
PaaS is designed to support the complete web application lifecycle: building, testing, deploying,
managing and updating.

PaaS allows you to avoid the expense and complexity of buying and managing software licenses, the
underlying application infrastructure and middleware or the development tools and other resources.
You manage the applications and services you develop and the cloud service provider typically
manages everything else.

PaaS Layers & Evolution (current applications)

Evolution

 Evolution of PaaS
In order to improve PaaS technology, it is going through many transformations phases since it has
been launched in the market. Currently, PaaS evolved to a great extent that business and developer
start relying and adopting it. has named this technology transformations in PaaS architecture as
“PaaS generations”.
Generation 01: This generation was based on classical fixed proprietary cloud platforms. AWS,
Heroku and Azure were initial technology platforms who initiated such services.

Generation 02: This generation platforms were developed around open source solutions. OpenShift
and Cloud Foundry were emerged as one of the top players of this generation. These technology
providers offered clients to run their own PaaS (in the cloud or on-premise).
Aforementioned, PaaS platforms also initiated the idea of containers and developed their own
container models. However, currently these PaaS vendors are transforming their approach and
moving toward improved technology models. For example: presently Openshift transferred from its
own container model to the Docker based container model. The same transformation performed by
Cloud Foundry, through its internal Diego solution.

Generation 03: Currently, third generation of PaaS is purely focused on container models. The new
PaaS platforms like Deis, Dawn, Octohost, Flynn and Tsuru are purely built on Docker based
container models. These platforms build around Docker from scratch. Moreover, these PaaS models
are deployable on public IaaS clouds or on their own servers

Platform as a Service(PaaS) is one area in cloud computing that had been widely overlooked by
developers and analysts for a long time. That is no longer the case though. A recent study by Forbes
estimates that the PaaS market will reach $7.5 billion by 2020.

PaaS Layer

Three Layers of PaaS

Three layers of PaaS

PaaS has evolved in recent years and now it not only refers to hosting and maintenance, but to
development of core applications and services. Platform as a Service or (PaaS) can be categorized
into 3 different layers:

1. IaaS-centric PaaS: automates many of the IaaS-related tasks, such as environment

preparation, run-time, deployment, etc. These services are also called classic PaaS or
managed IaaS services.

2. Generic PaaS: abstracts the underlying IaaS layer and creates a generalized layer of
infrastructure abstraction and virtualization to develop applications.

3. SaaS-centric PaaS: enables applications to conform and behave as per the SaaS principles
such as multi-tenancy. The underlying hardware and IaaS as well as run-time are completely
abstracted for application developers.

PaaS category

PaaS platforms evolved differently for different Cloud Service Providers (CSPs). However, we can
categorize these evolutions into the following areas:

1. Infrastructural PaaS

This type of PaaS service is geared towards handling operating systems, application run-time,
application hosting, auto-scaling, etc. For example, Azure App Service, AWS Beanstalk, Google App
Engine, etc. It is often referred to as Application PaaS (aPaaS) by Gartner.

2. Structural PaaS

After Infrastructural PaaS, cloud providers moved towards providing application services required by
applications such as queues, service bus, notifications, caches, etc. These services have their
infrastructural and implementation details abstracted from the users and only provide key concepts,
frameworks, SDKs, clients, and protocols to use in an application. However, this still means that the
code must be written for adapting to the defined schema and protocols to create business logic.
Since, these structural services are entirely managed and controlled by CSPs, these are referred to as
Structural PaaS. The idea behind adopting Structural PaaS services is to reduce time to market for
implementing common application support services and focusing on developing business needs.

Some examples of Structural PaaS are Azure Event Hub, Azure SQL Database, AWS document DB,
etc. Nowadays, these services also include container-friendly platforms which can handle the
provisioning, discovery, and routing of containerized applications. Such offerings are called
Containers as a Service or CaaS, e.g. Kubernetes, Mesosphere DC OS, etc.

3. Functional PaaS

Once we have established control over the PaaS infrastructure, the next job is to abstract all
information from the users and allow them to focus on business code.The run-time environment,
protocols, and schemas become just a configuration. Such type of PaaS service is more focused on
handling business and thus referred to as Business PaaS. For example: AWS Lambda, Azure
Functions, IBM OpenWhisk, etc. These services are also known as Functional PaaS (fPaaS or FaaS).

These services are more suited for spontaneous computing when you may
require computing instantaneously or as per schedule. For instance file uploading and processing,
etc., and handling event triggers such as file creation in storage accounts. A more mature offering of
business PaaS is called Mobile back end as a Service (mBaaS) where mobile-friendly back end APIs
take care of provisioning, scalability, and authentication of various mobile-based application
business functionalities.

Why Use PaaS/ Why PaaS has become so popular?

#1 Innovate Faster
First and foremost, using a PaaS to deploy and run your application enhances your agility.

The Web is accelerating the pace of innovation. To compete, you need to quickly transform new
ideas into real applications and evolve those applications with agility in order to meet fast-changing
business and technical requirements. Market opportunities exist very briefly. Your business needs to
build, deploy, and iterate in days or weeks, not months or years.

Setting up platform-level software to run your application is time-consuming and complex. 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.

It takes us 50% less time to deploy on Engine Yard Cloud because it’s so easy to configure servers.
We can deploy with just a few clicks and add another instance with just one more click—and on top
of it all, everything is pre-configured by Rails experts at Engine Yard who could write the book on
best practices for rapid deployment.

- Josh Krall, CTO, TransFS

#2 Focus Resources
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 means that you don’t
even need to know how to do them. 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.

Let’s say you’re an entrepreneur with a great idea and some seed funding, or you’re an enterprise
line-of-business manager with some spare budget you’d like to put on a special project. Do you want
to spend your precious funding on some generalist developers who can code moderately well and
also do system administration, or would you rather get top-notch coders who don’t necessarily have
deployment expertise? Would you rather spend a dedicated headcount on an ops person or have an
additional application developer?

By deploying on Engine Yard Cloud, we’ve saved at least 60% on engineering resources—this
productivity boost translates directly to more features and faster time to market.
- Chris McNeilly, CTO, Motista

#3 Save Money
Focusing development resources and spending less headcount on unneeded expertise are both
benefits that intuitively translate into reducing costs. But beyond these obvious things are even
more ways that PaaS saves real money compared with doing it yourself on IaaS.

With PaaS you are tapping into a real economy of scale. Imagine the number of hours it would take
to set up the core stack—the platform-level components—for your applications. Imagine the hours
consumed on an ongoing basis to maintain the stack. Imagine the cost of those hours, and consider
the incremental value from this work to your application. Now consider those same costs amortized
across thousands of applications. There is very little differentiating value from doing this low-level
work yourself, so clearly, buying platform from a provider is more efficient than building it yourself.

We estimate that our costs are 3-5x lower than if we had to pay the direct and indirect costs of
owning and managing our own infrastructure and deploying our large array of applications.

- Eric Peng, CEO, PlayMesh

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.

#4 Get the Best Technology

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. The top platform builders are in companies whose main business is platform. People who
are world-class in a given discipline for the most part want to work somewhere where that discipline
is core to the business, not in an ancillary or supporting role.
A PaaS typically employs specialists who constantly tune, optimize, load-balance, reconfigure, and so
on. The result of faster page loads is often a reduction in bounce rates, because customers are more
satisfied with the service level they experience. And since search engines use bounce rates and page
load times to prioritize paid search rankings, faster application performance can substantially
improve your application visibility and business performance.

We’ve mentioned the stack itself several times, and getting the best stack means getting a stack with
the latest versions of all components, configured optimally to work with each other and as the
foundation for applications such as yours. In addition to the stack itself, there is the deployment
mechanism, the platform software that instantiates virtual servers on the infrastructure and installs
instances of the stack on them. Many aspects differentiate a good deployment mechanism from a
bad one: what configuration parameters are exposed, what component options exist, how stack
versions are managed, what activities are automated, what components are pre-built into binaries
versus compiled at deployment time, and so on.

With Engine Yard, we can deploy our application in five minutes, and we know we’re running on the
best technology stack. If we were managing our own servers, we’d have to take resources away from
development to invest in a dedicated IT/infrastructure engineer. Instead, we’re able to focus on
building new features.

- Damon Danieli, Founder and CTO, Z2Live

Above all of this, there is the user interface, which may include GUI and CLI variants. Getting the user
interface and user experience right is make-or-break for platform interaction. The best platform user
interfaces will be simple yet flexible—the things you don’t care to customize shouldn’t get in the
way, and the things you do want to customize should be easy to do so. The interface needs to be
both learnable and usable—i.e. quick to get started with but also powerful enough to support the
expert user.

#5 Stay Up to Date
A particular challenge of deploying your application on a self-built stack is the sheer number of
components that need to be tracked, maintained, updated, and re-integrated over time. It’s one
thing to get it all set up and humming along in the first place, but the first time you need to swap in
an update to the app server or the load balancer or the cache you may find yourself in a nightmare
of reconfiguration. One bad experience like this leads many do-ityourselfers to remain indefinitely
on an increasingly outdated stack for fear of rocking the boat. The downside of course is that you
end up missing out on the latest security updates, performance improvements, and new features—
and what may have started as competitive advantage becomes a weighty impediment to keeping up
with your competitors.

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. You don’t fall behind your competitors, and you also don’t waste time and incur risk by
doing it yourself. The PaaS experts constantly incorporate and test component updates and bring
them into the platform. At Engine Yard, updates are rolled out in a way that minimizes risk of
incompatibility and gives you complete control over how updates are brought into your production
applications.

Engine Yard Cloud is a scalable, reliable platform that’s been developed and fine-tuned by cloud
experts. We have an easy and repeatable deployment process that is 200% better than managing
our own datacenter.

- John Schult, Director of Product Engineering, Vitrue

#6 Maximize Uptime
PaaS offerings can help you achieve your availability goals and give you innovative new disaster
recovery/ business continuity options. PaaS vendors have the tools, technologies, and experience to
help you avoid the unplanned outages that cause downtime. 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% availability. Engine Yard, for example, employs
application templates and configuration recipes that minimize human error, ensure up-to-date
snapshots of content assets, and allow fast and easy rollbacks if something goes awry.

Beyond basic data backup and OS hardening, PaaS vendors can protect your data in other ways.
With Engine Yard, for example, completed transactions can be recovered in the case of database
failures, so you never lose data from a committed transaction. And because application
configuration is all captured in application templates and recipes, it’s easy to reproduce your
application in another availability zone if the primary zone has a disruption. Engine Yard
automatically spreads your application across multiple availability zones, enhancing application
resilience.

#7 Scale Easily
It’s one thing to get the best technology at the best cost for a given size of business. It’s another
thing to achieve that at many different sizes—potentially spanning orders of magnitude—as your
business grows. 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 like 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. For example, to add instances in the Engine
Yard Cloud you simply click the ‘Add’ button, and a wizard walks you through a couple of
checkboxes.

We were the victims of our own success—we had so many people using our applications we
couldn’t keep up with the need to expand. On top of that, we’re a game studio, not an infrastructure
company, so we were inexperienced when it came to configuring servers to scale based on changing
traffic patterns. This is where Engine Yard really shines because scaling Rails applications is one of
their specialties.

- Eric Peng, CEo, PlayMesh

#8 Strengthen Security
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. At Engine Yard the stack engineering team maintains fully updated Rails and PHP
technologies, so security vulnerabilities in core language or framework components are quickly
remedied and customers are automatically notified following the patch.

#9 Do Your Project Right

An interesting behavior happens in real-world enterprises when departments or lines of business
can’t get corporate approval or fast enough turnaround to build and deploy a new Web application;
they tend to do it anyway. Through the back door. They go to a digital media agency; they re-
channel some discretionary budget and hire consultants; they get it done using the “easier to get
forgiveness than permission” principle.

These unofficial or back-door efforts usually result in a mess, sooner or later. At the very least, they
add to the complexity and inefficiency of the environment, because they introduce new and
unapproved tools, processes, and/or infrastructure. In other cases they create an even bigger mess:
what if the new Web service really takes off, and suddenly the LOB manager needs to procure
budget to scale up? What if the new Web service unexpectedly disrupts, corrupts, or causes
downtime in legacy applications? It might not be as easy to get “forgiveness” as presumed.
The best thing about relying on Engine Yard for our deployments is that they are dedicated stack
experts, so I can trust that they’ve selected battle-tested production configurations for Rails
applications. Because of this, we’ve reduced the time we spend each week on system operations.

- Nathan Phelps, Co-founder and CTO, HealthLeap

PaaS dramatically cuts the risk, cost, and complexity of new projects. It brings predictability to both
the cost and the ramifications of introducing new Web applications and services. To the extent
needed, a PaaS offering can complement and add value to existing development and IT operations.
Simply put, it doesn’t need to come in through the back door.

#10 Get the Best Support

As outlined above, when you build and run on a PaaS, you use technology that has been developed
and refined in response to the needs of thousands of customers. But it’s not just the technology that
embodies that aggregated expertise. It’s the people themselves. When you call Engine Yard Support,
you speak to someone who has 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.

Disadvantages of PaaS
Vendor lock-in
Affordable development tool kits and reasonable host pricing are readily available for businesses. In
most cases, companies won’t have to invest in costly servers or other infrastructure because it’s
handled by the provider. When demand increases, the payment model will continue to reflect usage.
Hopefully, as user bases grow, revenue follows, allowing for simpler expense forecasting. Still, some
users disapprove of some potential vendor lock-in when using PaaS offerings. Since your company’s
entire application is built on the platform, it can be difficult to change providers without affecting
functionality.

Changing PaaS providers would involve a significant workload and expense increase. All of the
application’s code and data will need to be migrated. All of the network monitoring and
configuration management operations will need to be restructured. Contracts will also need to be
renegotiated. It is possible to switch PaaS providers, but it can be time consuming, labor intensive,
and expensive.

There are four primary lock-in risks that you’ll take working with a single cloud provider. These
include:

1. Data transfer risk

2. Application transfer risk

 3. Infrastructure transfer risk

4. Human resource knowledge risk

Data transfer risk

It is not easy to move your data from one CSP to another.
A myriad of questions will arise during a data migration process, such as:
1. Who is responsible for extracting the data from the cloud databases and data warehouses?
2. In what format will the data be? Will that format work with the new cloud provider, or will
significant changes need to be made to the data?
3. How can the data be transferred without loss of application functionality?
4. How long will it take and how much will it cost to move all of this data?
While some industry groups have tried to create standards for data interchange, sometimes it’s
difficult for companies to implement them due to their unique business requirements.
Application transfer risk
If you build an application on one CSP that leverages many of its offerings, the reconfiguration of
this application to run natively on another provider can be an extremely expensive and difficult
process.
For instance, let’s say you’ve developed a business intelligence platform on Microsoft Azure. You
leverage basic cloud services like compute, storage, databases, and networking. But the app
also includes Azure’s machine learning, data lake analytics, and bot services.
Can you imagine all the changes you’ll have to make to your application if you had to move this
to another CSP?
One reason for this difficulty is a lack of standard interfaces and open APIs. Every CSP has their
own proprietary specifications and standards, which make it very tough to move from one to
another.
Another reason is that technology and customer needs change so rapidly.
You know first hand that your customers and partners continuously demand changes and
improvements to your product. The faster that you add and edit features of your cloud-native
application, the deeper entrenched you get with your CSP, and the tougher it will be to move to
another cloud vendor.
Infrastructure transfer risk
Every major CSP does things a little bit differently.
Virtual machine formats and their associated pricing vary from vendor to vendor, making it
difficult to ensure that you have the appropriate resource usage and cost savings if you switch
providers.
Database offerings and formats may differ as well.
And one cloud provider may have more attractive offerings in certain infrastructure components,
while lacking in other services that you may need.
These differences in the underlying infrastructure result in difficulties moving from one cloud
service provider to another.
Human resource knowledge risk
If you’ve been working with a single CSP, your IT team has likely gained a lot of institutional
knowledge about that provider’s tools and configurations.
If you have to move your applications to another CSP, it will take time for your engineers to ramp
up their knowledge of the new cloud platform. They’ll have to learn about new infrastructure
formats, implementation processes, and more.
Additionally, any newly required certifications will take a long time to earn.
The knowledge risk is a factor that isn’t often thought about, but is just as important as the risks
highlighted above

How to overcome vendor Lock-in

1) Do your due diligence
Before you select your CSP, you should thoroughly vet that they will give you everything
that you need to run your applications reliably.
Your CSP selection process should look something like this:
1. Determine your goals of migrating to the cloud
2. Assess your current IT situation, including a thorough audit of your current
infrastructure and cost and resources levels
3. Select the type of cloud environment needed – public, private, or hybrid?
4. Determine the specific cloud components necessary
5. Choose the right cloud provider for your situation
You should consider all of the CSPs’ offerings to see if they match your needs, look at the
different pricing models to determine the cost savings you can realize, understand their
service level agreements, consider their data transfer processes and costs, and get to know
other companies similar to yours with whom they’ve worked.
A deep understanding of your potential CSP is critical in mitigating the risk of vendor lock-in.
2) Design your application to be loosely coupled
To minimize the risk of vendor lock-in, your applications should be built or migrated to be as
flexible and loosely coupled as possible.
Cloud application components should be loosely linked with the application components
that interact with them.
You can do this by incorporating REST APIs with popular industry standards like HTTP, JSON,
and OAuth to abstract your applications from the underlying proprietary cloud
infrastructure.
Also, any business logic should not only be separated from the application logic, but should
be clearly defined and documented. This will avoid the need to decipher business rules in
case a migration to a new CSP occurs.
Not only does this reduce the level of lock-in to a single vendor, but it also gives your
application interoperability that’s required for fast migration of workloads and multi-cloud
environments (more on this later).
3) Consider a multi-cloud strategy
More businesses are moving to a multi-cloud environment, where you can leverage multiple
CSPs to power your applications.
For example, you might use Amazon EC2 for your compute power and Redshift for your data
warehouse while using IBM Bluemix’s Watson as your artificial intelligence platform.
By going multi-cloud, you become less dependent on one CSP for all of your needs. Another
benefit is that you can cherry-pick offerings from each cloud provider so you can implement
best-of-breed services into your applications.
There are some cons to a multi-cloud approach, such as an increased burden on
development teams, more security risk, and others. (See here for an in-depth list of the pros
and cons of multi-cloud environments.)
But you may find that it’s a viable option to mitigate vendor lock-in.

Lack of control
One downside of relying on a PaaS provider is that the product is vulnerable to downtime during
which users cannot access the system. Downtime is a necessary evil needed to improve and
maintain the platform, but if it occurs too frequently or at unannounced times, developers could be
left in the dark, basking in their frustration. Having a reliable system is key to launching an
application quickly and efficiently, so make sure you ask what the service uptime is and urge
providers to give advance notice whenever possible.

Hardware and software dependencies

Companies migrating a legacy application may have difficulty pairing their existing hardware to their
new provider’s hardware. Some applications require specific kinds of servers, data storage systems,
and networking components. Some cloud service providers will be able to accommodate these
needs at little to no cost. Some may not be able to meet your hardware needs, while others may be
able to accommodate your hardware requirements at an additional price point.

Programming languages and existing development software setups should be considered when
adopting a PaaS. One of the first steps you need to take when selecting a PaaS provider is to choose
which programming language you will use. Every PaaS platform supports a different set of
programming languages, so ensuring that the one you choose is compatible with your language of
choice is a crucial step in your decision process

Cost
The first question each business person will probably ask – what’s the price?

The problem with cost is that we are used to buying bulks of countable things, such as licenses or
hardware. Then, we add a bunch of services – per-server management cost, per-CPU performance
increase, per-hour engineering work – and so on. The nice thing about it (setting aside the fact it has
to be paid) is that it’s easy to calculate the cost.

But now, when everything is a subscription-based service, it’s not that easy anymore. Of course,
when you are more into SaaS (Software-as-a-Service, the kind of software you can take and use off
the shelf) solutions like Office 365, you usually think subscription = number of users using it per
month / year, then it’s still quite easy.
However, PaaS is not about users – it is about usage. It sounds similar but is vastly different. When
buying platform services, you pay for the use. What does it mean? Enter the best-for-all-occasions
consultant’s response: it depends.

Paying for usage

For some services it may be up-time minutes, for others – compute units (CU) time or performance
level tier. Pretty vague definitions and the fact that they are usually valued in micro-dollars (fractions
of a dollar) and per-minute use, don’t help in getting a grasp of what’s going on cost-wise.

The challenge boils down to one simple question: how much am I going to pay? And the most honest
answer to this is: who knows…

You can estimate how much it is with some probability, but you can never be sure of what the bill
will be. This is because once you get into PaaS, you will keep changing things, adjusting capabilities
or introducing new services. And you will do that constantly, just because you can, with ease which
has never been possible before!

So, what do I do?

One nice suggestion which I recently heard, is that you shouldn’t actually care. It is still going to cost
you less than if you had to put up servers for hosting similar services to the ones you’ve had before.
And I guess this is the best conclusion to stick to.

OK, but how will I make sure my budget ends meet?

The best advice is to observe and adjust service levels on the go and keep track of your weekly /
monthly use. If you don’t plan to dramatically change what you have, you should be able to keep
your weekly / monthly spending on a similar level going forward. Of course, set some budget aside in
case your users like the cloud too much and start using it more than you’d expect.

The future of PaaS

The PaaS market has not grown quite as rapidly as the IaaS and SaaS markets, but it has made
significant strides in recent years. The growing popularity of containerized applications and the
evolving microservices delivery model have significantly changed application development for
hundreds of companies. Simplifying PaaS delivery has added a lot of control for customers. They can
add or remove services as their needs change. Customers can even adopt cutting-edge artificial
intelligence or edge computing capabilities with ease.
PaaS and IaaS are slowly blurring together as hybrid service models attempt to deliver complete
control to the customer. The two technologies have formed a symbiotic relationship. Companies can
build their application with PaaS and manage or scale with IaaS control. Companies that can afford
both fully fledged IaaS and PaaS offerings can gain full control over infrastructure, resources,
networks, and code.

Low-code
PaaS-esque solutions such as low-code development platforms have increased in popularity in
recent years. These tools simplify the development process while providing managed backend
services. Many of these products combine templated applications and prebuilt backends with
customizable code or drag-and-drop interfaces.

Companies with smaller development teams or individuals with minimal coding experience can jump
in and create interactive applications or customized workflow tools. Some individuals do have
concern about non-programmers building applications, but the technology has made it easier for
user experience and design experts to take more control over the development process.

Containerization
Containers have taken world by storm, becoming a billion-dollar industry in just a few years. By
2020, the industry will be worth upwards of $2.6 billion, according to 451 Research. The technology
is built around the idea of isolation and abstraction. Containers possess everything they need to
operate (runtime, code, and libraries) within a single construct. Companies have used this
technology to improve security, increase technology time, and simplify configuration management.

The number of companies using container technology is steadily growing. Many employees from
corporate giants have reviewed containerization software products on G2 Crowd. The most common
are Docker and Kubernetes, two container management solutions. Many cloud service providers
have even begun offering cloud-based container management solutions such as AWS ECS and
Google’s GKE.

The internet of things

The internet of things (IoT) has forced a number of industries to evolve. Nearly every household
device or business tool can be connected to the internet. As a result, many PaaS vendors have
released offerings to meet the needs of cross-platform applications operating on disparate devices.
IoT management solutions, many of which are offered by PaaS providers, are used to build and
manage scalable multi-tenant IoT applications.

Since everything is connected to the web and thousands of IoT apps have hit the market, a plethora
of data emerged from an untapped source. Streaming analytics technologies came to power as a
practical solution. These tools can monitor devices in real time and help companies better
understand users while improving application performance. They also help integrate these large,
continuously growing datasets into third-party applications.

It’s important to stay in the loop as the PaaS market continues to grow and cloud services expand
their capabilities. These tools can help companies go from archaic non-factors to industry
innovators.

Visit our platform as a service (PaaS) category to stay up to date on the latest offerings and top-rated
solutions. Whichever software or services you use, share your personal experience in the form of a
review on G2 Crowd to help fellow professionals around the world with their business buying
decisions..