DevOps is just the beginning
DevOps and Continous Delivery combine some expectations and promises. In addition to the seamless transition from development into production, there is the promise of a generally more efficient development process through the Continous Delivery Pipeline, not at least through the savings of personnel on developers and on the tester side. (DevOps Strategies)
At the beginning, however, there is an investment for the delivery pipeline, along with the introduction of the corresponding development and testing processes. The investment and the creation of the accompanying DevOps strategy is a major challenge for many companies.
This investment can be greatly reduced if a company uses a Server Less Computing platform.
Server Less Computing
Server Less Computing (SLC) is a new buzzword for a cloud-based approach to provide developers with resources in the cloud for the execution of their functional code. When using an SLC platform, it is not necessary for developers to worry about infrastructure capacities, such as virtual machines or storage space. They are also typically no longer bothered with infrastructure CIs, e.g. Server nodes, network components, or middleware.
This applies to both development, test and production environments on SLC platforms.
There is no contact person or DevOps Engineer on the provider’s operating side, in the event that problems occur.
- It is, of course, clear that „Server Less“ is not to be taken literally. It is only that the application developer does not know anything about the server infrastructure.
The major providers of SLC platforms are Google, Amazon and Microsoft. On these platforms, large systems and small applications can be operated equally.
Since the connection to SLC platforms takes place via the Internet, no SLA is possible without additional measures, such as a „Leased Line“.
Strictly speaking, the SLC approach is a NoOps approach because, as described above, the developers have no contact to operational processes. Thus, there is no DevOps engineer in place. The application developers come up with the knowledge about the basic architecture of the respective SLC platform.
This knowledge is similar to the knowledge that mainframe developers have on their mainframe platform.
Mainframe platforms and SLC platforms have several aspects in common:
- The complete abstraction of the underlying hardware,
- The availability of different development and test environments besides the production environment
- A mechanism for the seamless transition of an application from development to test into the production environment.
- The proprietary nature. Applications as a whole cannot be easily ported between the SLCs.
It is therefore to be expected that SLCs develop into „Cloudframes“.
This proprietary nature has ended the use of mainframes in many areas where lower security and throughput requirements could not justify the high cost of a mainframe. Instead, small and fast systems were used for client-server systems. This was done at the cost of additional infrastructure expenses for the quick creation.
However, the disadvantages of the closed systems Cloudframes / SLCs is largely compensated:
- Scalability – by the modular nature and the possibility to develop modularized applications. Such a WEB-based application can then be developed and operated in parallel on several SLCs
- For SLC platforms different price models exist, which are very favorable depending on the availability and the useful life.
- The developers have the choice to opt for a single Cloudframe, or distribute different modules on Cloudframes from different vendors
- A uniform interface to the user exists for all SLC platforms. This is the WEB browser for all stationary and mobile devices.