With the advent of DevOps and various Platform-as-a-Service (PaaS) environments, many complex business requirements need to be met within a much shorter timeframe. The Internet of Things (IoT) is also changing how established applications and infrastructures are constructed. As a result of these converging trends, the enterprise IT landscape is becoming increasingly distributed, and the industry is starting to map how all the various components — from networking and middleware platforms, to ERP systems and microservices — will come together to create a new development paradigm that exists solely in the cloud.
Never start from scratch again
When today’s project teams start something on a greenfield, it poses numerous questions. Basic conditions and requirements can be put to the test and scrutinized without any reservation. A core team or individual often makes key decisions. However, in this new development paradigm, companies will use internal or central online repositories to locate established components, instead of long, subjective, selection processes. Additional metadata can also flow into an evaluation.
Those middleware components, development environments, or already-developed services contain all necessary information. The containers can be clicked and downloaded to the workstations, and selected components are assigned a corresponding project profile and version number. The generated profile can also be provided to individual developers in the cloud. From here on out, the developer is only one small step away from pre-configuring the entire project, including source code repositories and the corresponding quality assurance mechanisms.
The integration of containers and dynamic runtime configuration
For small, locally based teams, this paradigm shift already represents simpler workflows. When developers no longer think in terms of traditional middleware components but rather in terms of cloud services, it will become far more interesting. For example, microservice architectures are unlikely to run locally on one single development computer, even for testing purposes. What’s more, it’s unlikely that one project will be responsible for all services. This means that the entire application landscape also needs to be transferred to the cloud. This new development environment should enable seamless component migration instead of complex configuration and deployment scenarios with extensive manuals. It’s possible that only the runtime container will be changed, or it could be that the entire configuration will be carried out separately and centrally.
The IDE connections will also be directly adapted during this kind of migration. Instead of a local database there will be a cloud-hosted version. The local ActiveMQ broker is also transferred to the cloud and will offer high availability. The user server is clustered and now features a load balancer. A large number of these kinds of cloud-based middleware offerings are therefore components of the development and runtime environments of tomorrow. Profiles and containers contain binaries and configuration files that will be dynamically adapted according to the individual landscape. There are hardly any noticeable changes for the developer, apart from the fact that connections no longer run on 127.0.0.1 and are now available via IP addresses in other networks. The switch from local services and containers is carried out transparently and is divided into core services such as storage, CPU, and their integration into customized cloud services. This simplifies not only the operating of complex landscapes but their development, too. Messaging (Messaging-as-a-Service) and virtualized data models provide an uninterrupted connection to many different systems when components are networked via high-performance systems. Figure 1 illustrates what this new integration would look like.
Figure 1 — iPaaS =Integration PaaS. The iPaaS environment integrates different legacy applications and data, and provides unified access for services.
It’s hardly necessary anymore to define specific brokers or endpoints as all of the involved systems have access to the metadata. The brokers and endpoints will only be accessed based on service names and mappings. The infrastructure helps resolve IP addresses and ports. iPaaS knows which of the services running on the physical hosts are connected to other ones. Requirements such as scaling, clustering, and failover are reduced to buttons, which are transparently depicted in hardware properties such as IP addresses and ports without need for further action.
Business processes, smartphones, and the Internet of Things
Developers in this new development environment will need to consider concepts such as choreography, rules, and processes in far greater detail than before in order to break away from inflexible user interfaces and adapt these to changing specialist requirements. A new middleware service has been integrated for this purpose. Business process management in the cloud provides its services to the applications in the exact place where they are brought. The additional functions in the development environment are directly available and the bpmPaaS also identifies the already existing interfaces and databases (see Figure 2). APIs are consistent, easy to access, and documented across all services.
Figure 2 — bpmPaaS= Business Process Management PaaS. In combination with iPaaS and mPaas the focus on developments in the future relies on models, regulations and processes.
The application does not only continue to develop from an internal perspective. The many new, networked devices offer a huge number of opportunities alongside intelligent sensors, portable devices, and smartphones. Applications should be able to interact with updated versions or device functions, immediately if possible. User friendliness and safety should also by no means be neglected. The most common challenges in the field of mobile devices can be overcome with mobile Platform-as-a-Service (mPaaS) solutions, as shown in Figure 3 below.
Figure 3 — mPaaS = Mobile PaaS. Device specifications are abstracted internally and externally through uniform interfaces, and access is being simplified.
These services support device registration and compliance with safety standards. Companies can also develop the ongoing trend of ‘bring your own device’ using extended measures. Intelligent, standardized interfaces between mPaaS and iPaaS enable targeted, controlled connection to the relevant back-end services, even within the most complex network and service topologies.
Once the work is complete and the application fulfills its purpose, the development project can focus on new tasks and return to business as usual. In this new development environment it won’t be necessary to pass on expertise or provide training sessions for the new team. The entire application can be searched and examined in detail at a wide variety of granularity, from complex dashboards with an overview of service agreements and interfaces right through to individual code strings. This helps the team to identify and resolve any possible problems.
Brave new world?
The complex, distributed, and heterogeneous application landscapes described in this article can already be created using today’s tooling. But up to now, very few genuine success stories have been identified and published. With that said, a couple of excellent approaches for implementing this new development environment have already been launched, and the ongoing container trend enables plenty of opportunities to get started working with these design principles.
Public domain platform image via Pixabay.