PaaS Motivation –
enabling infrastructure for truly liquid application design.
Key Words: GCE, Docker, Meso,
Kubernettes, and Swagger and Micro services?, liquid applications, Containers,
PaaS, Fig, Digital Experience.
As
I take on my new role and interest in diving deep into – Platform as a Service
– PaaS world, I wanted to take some time in discussing what I know now AND how that point of view may
shift as I learn more about the PaaS evolution. While en route to IBM
InterConnect 2015, I figure I jot a few thoughts and reflect on my past
encounter with Cloud, more specifically PaaS.
In my previous post titled “Cloud,
Mobile, MBaaS… How do we make sense of it all” - I discussed the trends that
drive the innovation to make the application design more liquid. But before
spend more time discussing what a liquid application design means; I would like
to define a few commonly used terms in Cloud parlance.
The terms described below have evolved to
provide a structure and concept consumption around Cloud paradigms:
IaaS –
Infrastructure as a Service (Essentially HW + OS + Other Network services)
PaaS –
Platform as a Service
(IaaS + Platform technologies such as Middleware/Directory services etc)
SaaS –
Software as a Service
(Bring your Mouse and yes.. your skills.… and provision and configure/consume
services)
I also discussed that digital experience driven
trends that may tip the scale in driving the cloud patterns to new heights. But
before we discuss these trends and technologies we need to understand drivers
responsible for the resurgence in cloud consumption. While every enterprise is
racing to define their approach to liquefying application design, be it,
Mobile, Social, Cloud or Dev-ops, I do not view them as separate disciplines.
In Fact I view them as a singular discipline that aims to surface a digital
strategy – a platform that enable information dissemination, interaction and
engagement.
So what is a
Liquid application after all? If
I were to define a liquid application design
it would be a design pattern that hinges upon a paradigm that is loosely
coupled and leverages the data and
business logic to derive intelligence regardless of underlying limitation of HW,
networking, virtualization platform, programming languages, and legacy
application design approaches. While this definition may seem too broad let me
attempt to dive a bit deeper.
While IaaS layer is to enable the use of fundamental
computing resources, such as, storage, networking, hardware, memory etc and
enable enterprise to leverage computing power to maximal advantage. PaaS
motivation on the other hand is to further exploit the flexibility enabled by
IaaS layer to enable ease of movement of data, application code, logic,
configuration and associated application artifacts.
Platform frameworks such as
CloudFoundary, GCE – Google Cloud engine and container frameworks like Docker, Meso, and Kubornettes aim to provide
the fluidity towards achieving the holy grail of liquid application design. Container frameworks such as Docker for
instance advocate no reliance on any external environment. In fact, container
app paradigm advocates a self-contained environment where you store all config
values, dependencies, everything inside of the container itself.
The
focus here is decoupled applications that rely on a fluid discovery and network
infrastructure to resolve operating dependencies and communicate with other
applications. Apps communicate with the rest of the world via ports and via Dockers
itself. The trade-off is that apps become a little bit bulkier (though not
significantly), but the benefit is apps become maximally portable.1
This concept has given rise to discussion around containers and micro
services. This also means that software
defined networks is essential to achieve a true PaaS infrastructure. More on
this in future posts…
In
this post I would also like to draw attention to understanding the
drivers responsible for the resurgence in cloud consumption… all driven by
digital experiences and it’s
derivatives. ( I have discussed these concepts in my previous posts)
a.
Software and Data
Ownership
–There is a complex relationship between
the data ownership and software ownership. Clients want to own the data and not
the software ( due to licensing costs and maintenance). This leads to
interesting conversation around traditional hosting/resource provisioning and
ability of an enterprise to just create Mobile application services and provide
an integration point to the enterprise.
This model allows the enterprise to control data access and ownership
and yet keep up with the modern trends in the industry at relative low costs
without extensive capital investments into software ownership. Think of this
more like a “Software rental”, a concept that
lends itself to Hoteling or multi-tenancy.
b.
Burden
of System Management – With IT systems and managers driving for efficient
consolidation adding another tier of
system management to address Mobility can be a daunting task, besides
monitoring and analysis of critical business objectives gets the time share. So
the notion of provisioning, managing and monitoring system like Mobile device
management, MBaaS services ( Mobile Backend as a service) is preferred to be managed and
maintained in cloud.
c.
Continually evolving
Mobile and API Eco-system – Our clients have, in the past, spent time and money to
harden the infrastructure and handle the
evolution in middleware Infrastructure
and platforms. There is little or no appetite to deal with a much rapid force
of changes with in Mobile Eco system that has direct impact on the existing
infrastructure. The assumption here is that the cloud based services will keep
up with eco system evolution such as notification systems, MobileOSs, and new
and emerging mobile-social integration points ( such as OpenAuth, Social
updates and notification and API economy) and enterprise get to use and keep up
wit the changes by association. Thought to ponder upon here is how do Mobile Infrastructure
Cloud service provide keep up with this rapid change? What are their
challenges?
d.
Ephemeral nature of Mobile/cloud
Application landscape
– As discussed earlier rapid shift in the mobile landscape driven primarily by
the MobileOS vendors and Mobile services ( NFC, Payment, Notifications etc),
many client hesitate in locking in an on premise platform as many question the
ability of these vendor provided platforms to keep up with the changes in
marketplace.
e.
Changing mindset around
investment and consumerization of Mobile/application platforms – As our clients are
still in process of defining their ROI
expectations and as business evolve to adapt to Mobile way of doing business,
there is clear lack of leadership and the idea of disengaging or switching
providers not only makes business sense but also addresses the long term
capital justification concerns. Mobility in cloud seems a more palatable and
economically viable option. Unless there is a
defined business value or a ROI around ownership of mobile platforms,
this will be a “rent vs. buy”
discussion.
f.
Social ’ization’ of APIs
– With
emergence of Mobile API services offered by the social media eco system, and
other vendors like Twillio, Google etc clients have eased into “service
virtualization’ concepts and are more comfortable with cloud based models.
After all many B2C application rely on this emerging and burgeoning API
economy. (reading: Look at Programmable Web, API.io, Swagger)
So while very definition of Platform is
in flux I think it is reasonable to say that the PaaS as a
concept and discipline is evolving. I plan
to discuss more on container technologies, networking and PaaS platform
component in my next post.
Stay
Tuned…
Interesting Reading:
6.
Web
API management - http://www.informationweek.com/whitepaper/Business-Intelligence/Business-Process-Management/web-api-management-new-rules-for-a-new-economy-wp1367342058?articleID=191708409&download=true&popup=true
9.
Rackspace
Cloud Mobile Stack -http://www.rackspace.com/cloud/mobile-stacks/
