Nearly all software developed today is based on middleware. For decades, middleware has simplified and standardized...
the development process for data center applications. Today, middleware, in the form of platform as a service, is harmonizing cloud development and deployment and, in some cases, facilitating hybrid cloud development. It's logical, then, to wonder how PaaS and data center development are similar or different in terms of trends and drivers.
Two distinct forces are behind the growth of data center middleware, the application framework created by the operating system and the needs of the applications themselves.
Virtually every enterprise has a large commitment to Microsoft Windows and to the .NET middleware tools, and an equal number rely on Linux-specific tools or platform-independent tools based on Java. Within each of these operating system segments we have tools for message management, deployment, database and others. These tools simplify and standardize development by providing common, easily adopted strategies for basic programming tasks.
Virtualization and cloud computing introduced a new class of middleware, related first to the special needs of virtualized resources and second to taking advantage of virtualized-resource benefits. Some cloud middleware has been collected into cloud platform tools to build a platform as a service, or PaaS, cloud model. To make matters more complicated, some vendors, such as Microsoft with its Azure PaaS platform, position their offerings as an alternative to generalized and popular infrastructure as a service (IaaS) cloud services, dominated by Amazon. This PaaS model includes features that are cloud-specific and others that are normally present in data center middleware.
PaaS middleware facilitates development by simplifying tasks that can be related either to what an application does, meaning the basic logic, and where the application runs, meaning how resources and connectivity among components is managed. Some PaaS models extend data center middleware platforms into the cloud. Some ask users to deploy a new PaaS platform on their cloud providers and also in their data center. Some provide cloud-specific tools and features largely independent of "what-it-does" middleware tools.
Microsoft Azure is an example of a data center middleware tool set (Windows Server, .NET) that is offered in a cloud PaaS with the additional capabilities needed for cloud deployment and application management. When Azure is used correctly, applications are highly portable between data center and cloud and the same broad practices work for both as well. Users building new data center applications must consider the cloud-side (Azure) issues to retain cloud portability.
The second model for PaaS is the "portable platform" model, embraced by Red Hat Red Shift and CloudFoundry. This creates a set of tools/APIs for deployment resource management, packaging them as a platform that is customized either to the cloud or data center as appropriate. This approach can be seen as a somewhat less intrusive equivalent of adopting a private cloud. Traditional middleware, dealing with application functionality ("what-it-does"), can usually be added "above" the PaaS platform.
The third PaaS model creates the platform from specific cloud-hosted platform services, such as Amazon's growing repertoire. These include database and network services that would be available in the data center, though usually in a slightly different form. Applications developed with this set of platform services would still be at least somewhat portable.
Amazon and some other providers offer richer services designed to influence application design, such as mobility services, personal worker services like calendars, and analytic services. Amazon recently added IoT services. This second group of services may not have any close data center equivalent, or any equivalent at all; applications that use this kind of PaaS service would not be portable, either to the data center or to another cloud provider.
The question for developers and planners today is how these advanced platform services would be integrated with the two other PaaS models. One possibility is to incorporate platform services into the PaaS, which means finding a way to implement them on premises. The other is to presume that platform services will be added "above" the PaaS model, almost like a microservice.
Cloud-centric development is based on the presumption of elastic resources for each component and dynamic workflows among them. This presumption is best served through a greater level of componentization than would normally be justified within the data center. Cloud-centric application design is also more likely to avoid traditional stateful SOA APIs in favor of REST and back-end state control. This model makes it easier to horizontally scale or replace components.
Hybridization impacts the picture by limiting the extent to which applications and components can be written to depend on cloud/PaaS middleware. Remember, PaaS middleware usually focuses on application lifecycles rather than logic. In hybrid cloud deployments, the cloud and data center sides will be decisively different in most cases, which means that it's unwise to build components that employ PaaS middleware integrated with the application logic. You'll need to maintain a separate component version for the hybrid cloud. This, of course, is why companies like Microsoft and Red Hat promote a form of PaaS that is naturally able to support hybrid deployments without multiple versions. Just remember that this won't always be the case with PaaS.
Laying the groundwork with a PaaS model
Comparing PaaS vendors
2016 app dev trends: PaaS, MBaaS, Spark