aPaaS allows for rapid application development and delivery. This form has high productivity and high control. The coding process for platforms as a service can slow down delivery, but aPaaS brings automation for the application lifecycle. aPaaS offers a faster way to build apps.
The application platform sits between software as a service (SaaS) and infrastructure as a service (IaaS). aPaaS, like IaaS, includes infrastructure – servers, networking, and data center storage – but also operating systems, analytics, database management, and development tools.
SaaS is essentially software that is always available online, easily accessible through subscription and often updated without disturbing the users one bit. Examples of SaaS are Netflix and Spotify.
SaaS may be built on top of aPaaS, but this isn’t a requirement. In the case of APIfoundation, we build all our apps on our own platform. And you can do this too.
- What is the difference between iPaaS, aPaaS, SaaS? - aPaaS.pl
- Strona informacyjna - github.com/apaas-pl/www
Pre-integrated stack of technology that we call "platform" should have happened around the 2003 timeframe. Hence the PaaS solutions we know of today in my view are only a necessary condition and not sufficient to really help large enterprises with where they need to go.
In the pre-cloud era there were:
- no platforms
- only products
- IT departments (in big enterprises) had different structue, with "enterprise architecture groups" that defined the platform for their enterprise.
- They hand-crafted a platform definition standard for their enterprise by combining various products like:
- app servers
- web servers
- databases
- middleware
- integration servers
- portal servers
- workflow engines
- ...
That is the only way they could manage the IT software infrastructure of very large multi-country, multi-location enterprises. Every large enterprise had its own blueprint platforms and they did a lot of heavy lifting not directly connected to their business outcomes.
This presents an opportunity to move away from large capital technology expenses and align technology costs directly with business growth
- Modeling driven process/app development
- Fast, Iterative, Visual, Collaborative
- Businnes ValueLiason with LOB
- Shared Serrice and Support
- PLatform Capability PLanning & Alligment
- PLatform Capbility
- Shared Common Infrastructure
- Architectural Stack and App PLatform
The platform goes beyond the technology stack. It is a platform that drives business innovation to the core and leverages the knowledge that lies in the fringes of enterprises, where lines of business and enterprise IT come together in bringing to life innovation solutions for their enterprise:
- agile on each level
- rapid prototyping
- collaborative platform
Collaborative platform for business and technology teams
-
enterpise IT
-
line of businnes
-
all is streaming zamiast zarządzać infrastrukturą, kreaować ją z inteligencją w odpowiedni spersonalizowany strumień danych i funkcjonalnośći zamiast sformatowanych iu zdefiniowanych struktur aplikacji i baz danych.
The big three—and most common—are:
- software as a service (SaaS)
- infrastructure as a service (IaaS)
- platform as a service (PaaS)
The third party is providing the software or technology in a subscription business model. SaaS, IaaS, and PaaS are widely accepted and understood by most organizations.
- Customization and configuration
- Accelerated feature delivery
- Open integration protocols
- Collaborative and social functionality
iPaaS has integration orchestration, a set of pre-built connectors to standard cloud services and popular on-premise enterprise software like SAP and Oracle Apps. it is easier to make vendor choices in this category compared to aPaaS
IPaaS can be addressed as a platform solution where you can manage and develop connected application integration in one place.
- Integrated & Co-located Suite of cloud services for integration & governance initiatives
- Cloud enabled Integration PLatforms CEIP
- eCommerce B2B, SOA, Integration Middleware
- Scalability
- Cloud-specific functions
- Management of integrations
- Capable of integrating new & legacy applications
aPaaS allows for rapid application development and delivery. The coding process for platforms as a service can slow down delivery, but aPaaS brings automation for the application lifecycle.
The aPaaS provides app development projects with underlying infrastructure and a software layer for the actual development and design. Instead of installing a downloaded development tool or using a coding tool to create your application and handing it off to be deployed
- you are subscribing to a service that provides all that for you.
aPaaS give tools to build and deliver apps much faster.
- Reusable components,
- visual IDEs
- abstraction and automation streamline application development
- provisioning and deployment.
The aPaaS it's opportunity to build applications while enabling professional developers to bypass repetitive, boring tasks so they can focus on solving business problems with unique applications.
"Independent Software Vendors" (ISVs) that build SaaS using a PaaS solution Enterprises that need to build applications that are specific to their needs and differentiated from their competitors.
The business goals and motivations of these two buyer groups are in many ways completely different as you can see from the diagram below.
- Development & Deployment of multi-tenant elastically scalable Business Apps
- Cloud enabled Application Platforms (CEAP)
- Composite Business Application Platform
- Scalability:
- load balancing
- failover
- Web-based user interface
- Multi-tenant architecture
- Services to develop:
- test,
- deploy,
- host, and maintain applications
Low-code application development is more a method than a service.
- visual IDE
- one-click deployment
- code generation
- and more automatisation
In fact, there are on-premises installations of low-code platforms. However, it’s no accident that Salesforce, Appian, Mendix, and OutSystems appear in lists of aPaaS examples.
Enterprise IT leaders want their teams to have a highly productive development platform instead of figuring out the nuts and bolts.
As we all know, a line of business always has "This is needed yesterday" type demands.
- Hence, time to market to stay ahead of their competition is a primary motivator
Every year there are additional governance needs. Enterprise IT knows the easiest way to address governance is by reducing the moving parts.
- Abstraction is the mantra here.
Enterprises are into their main business of making cars or digging of oil or providing healthcare. They don’t make money selling software. For them, software is a means to an end.
- Hence the platform of the future needs to address this "means to an end" goal
ISVs look for fine-grain control to be able to choose all the moving parts that go into the platform. This is one of the reasons ISVs generally tend to take the Infrastructure-as-a-Service (IaaS) route instead of the PaaS route.
Ability to service multiple customers on the same infrastructure and take advantage of economy of scale and load offsetting.
This is an additional dimension of control, but in a different plane. For example, an ISV may have legitimate reasons for not using ORM (Object Relational Mapping) for their SaaS application and prefer instead to do something on their own. Their SaaS application might demand that.
Breadwinner - ISVs’ SaaS offerings are their breadwinner, revenue generator and their IP. They are protective and possessive about these offerings, and this drives lot of their decision making in the kind of platforms they choose.
With this classification of meta-data aPaaS and programming aPaaS, a better picture of the vendor landscape in aPaaS emerges.
- aPaaS players can be classified into "meta-data aPaaS" and "programming aPaaS"
- Meta-data aPaaS doesn’t mean that there is no possibility of coding
- 80 percent is meta-data modeling, abstraction driven and APIs
When choosing an aPaaS, enterprises need to look for an aPaaS that:
- Creates and manages business objects and not code
- Allows resorting to code for extensions
- Defines business processes through a workflow engine
- Implements logic using business rules instead of burying them in code
- Includes drag-and-drop UI creation for easy change management
- Ensures all business objects are SOA compliant through REST/SOAP
- Provides multi-device support
- apps should be accessible from desktops and mobile devices including laptops, tablets and smartphones
- Provides a library of template applications to get off the ground quickly
- Enables the ability to run on-premise and in private and public clouds.
- This is a very important criterion when choosing a "platform of the future" especially in an enterprise context
- iPaaS is less complicated than aPaas to implement as a Service
- History has proved time and again that large established incumbents rarely offer paradigm shifts.
- Enterprises need to look beyond their comfort zones into new players that offer aPaaS that could put them ahead of the competition.
They roughly map to the integration middleware and application middleware in the pre-cloud paradigm
Today’s modern trend is to build applications using the Cloud-Native approach which revolves mainly around the following buzzwords:
- Microservices
- DevOps
- Continuous Delivery
Let’s see how these concepts actually affect our decision of dockerizing our app.
By adopting the microservices architectural style, we end up building a single application as a suite of small services.
- Each services running in it's own process and communicating with lightweight mechanisms.
- These services are built around business capabilities and independently deployable by DevOps (fully automated deployment machinery).
So, committing to this architectural approach most of the time implies developing and delivering our front-end as an independent service.
The adoption of DevOps culture, tools and agile engineering practices has, among other things, the nice effect of increasing the collaboration between the roles of development and operations. One of the main problem of the past (but also today in some realities) is that the dev team tended to be uninterested in the operation and maintenance of a system once it was handed over to the ops team, while the latter tended to be not really aware of the system’s business goals and, therefore, reluctant in satisfying the operational needs of the system (also referred to as “whims of developers”).
So, delivering our app as a Docker image helps reducing, if not removing entirely, the difference between running the service on a developer’s laptop, the production environment or any environment we may think of.
By leveraging the Continuous Delivery discipline we build our software in a way that it can potentially be released to production at any time.
Such engineering practice is enabled by means of what is normally called continuous delivery pipeline. The purpose of a continuous delivery pipeline is to split our build into stages (e.g. compilation, unit tests, integration tests, performance tests, etc.) and let each stage verify our build artifact whenever our software changes. Ultimately, each stage increases our confidence in the production readiness of our build artifact and, therefore, reduces the risk of breaking things in production (or any other environment for that matters).
So, creating a Docker image for our app is a good choice here because that would represent our final build artifact, the same artifact that would be verified against our continuous delivery pipeline and that could potentially be released to production with confidence.