This series discusses the requirements we face as developers when handing over a web application to an operator. In the initial post, I will categorize the different kind of operators and applications into 3 scenarios. Sequels will elaborate on various operational aspects. Thus the series will progress from the general to the specific.
But there is no Hand Over in our DevOps landscape anymore?
According to the tenants of DevOps, our topic should be a non-issue: The dev team continues to be responsible for its code in production and the environment is the public cloud. In realitiy however many cutomers operate their applications on premise or in a data center. Legal restrictions prevent pubic cloud hosting or true DevOps.
What remains of the DevOps idea, is the responsibility of the devlopment team for the fullfilment of operational requirments, where in a more traditional environment, this ould lie with a framwork team. The developers thus gain in autonomy, the inefficiencies associated with shared responsibilities are reduced and the team can work in an agile maner.
We therefore have to deal with the mutual requirements of operations and development and derive optimal solutions for our customer, as we are wont to do in the case of user requirements.
Many of the observations are applicable for a SaaS solution operated by the development team in DevOps fashion. However SaaS requries a wider scope as new responsibilities arise (e.g. design of the production environment). This widening scope is a characteristic of the transition from software product to SaaS offering and applies to other areas as well (e.g. product management).
Different types of operators
Enterprises of a certain size or with an IT oriented business model maintain large data centers. These have expertise in all relevant fields, so they are likely to be rather opinionated about any aspect of production. For many of these aspects there will be a system of infrastructure and processes in place that has to be adopted.
Customer specific development work actually benefits from these blueprints, als many repsonsibilities can be delegated away from the application to the surrounding infrastructure.
Standard products however are likely to face at least some requirements that with contradict their own design. Runtimes or libraries used by the application migth be in conflict with guidelines – most likely due to security or licencing concerns. The application might rely on systems odr protocolls not supported by the operator for the specific topic, so an integration layer may become necessary.
Driving change in major data centers requires a lot of efford as is typical for huge ogranizations. Decissions take time, especially if your customer’s customers have to be involved. This forces early commitments which can result in the following challenges:
- Requesting infrastructure (e.g. messaging systems) requires a long lead time
- As hardware procurement is a lengthy process, binding information on hardware sizing has to be provided so early, that a prototype for load testing ist not availiable.
- The preparation of information and training material for end-customers requires complete UI-designes or prototypes early in the process.
- As mentioned above operator manuals including detailed configuration instructions have to be provided early.
The central requirement of small or medium sized companies is that the application can be operated with ease. The limited staff of operations departments depends on complete solutions that do not rely on complex infrastructure.
In some respects, the advantages and disadvantages of this type of operator are the inverse of the case described above. While data center operations provide out-of-the-box solutions for many aspects, these aspects have to be covered by the application itself for a simper operation. On the other hand a simple operation poses less boundary conditions than a data center. Additionally the lead time for decisions tends to be shorter.
To avoid missunderstandings: Flexibility or the lack of boundary conditions means that the solution is not limited as much. It does not mean that there are no requirements. Indeed business critical applications, especially in regulated business areas as financial services face hard requirements as well.
Typical requirements of this type of operator are:
- Operational requirements are covered without requiring a large infrastructure.
- Typical operations use cases (installation, migration, etc…) can be excecuted effordly.
- The latest technologies might not be availiable. This affects plattfroms (e.g. Kubernetes) and protocols (e.g. OIDC).
If one is dealing with the change of existing systems, any kind of operator traditionally favours stability. The natural contradiction of development advocating change and operations advocating stability has been the main motivation of the DevOps movement.
Different Types of Application
Currently any discussion of application architecture starts with the difference of monolith vs. microservice. These two architectural patterns take a fundamentaly different approach to operational requirements. Traditional applications (monolithic is a bit narrow since traditional systems can very well be distributed) fulfill these requirements on the application level, while microservices fulfill them on the deployment level.
As an example consider HTTPS. A traditional application will provide an API that can be configured to use HTTPS. In a microservice environment, one typically deploys into a cluster. Within the cluster, the communication uses HTTP, while any communication with the outside is routed via an ingress server. This ingress server uses HTTPS for outside communication. Another example is the multi-tenant requirement. A traditional Application will connect to different data sources depending on the tenant information in the request – a microservice application will instantiate one service per tenant and route the requests accordingly. The application thus is not required to deal with multi-tenancy at all.
As an aside the difference between traditional and microservices applications is an essential element for the success of true DevOps. The isolated nature of a microservice enables a development team that is not specialised on operations, to look after the component in production. This is much harder for a traditional application, especially if it is depoyed using different integration layers to support a range of platforms. In this setup, DevOps tasks will likely overwhelm a development team and cause a drop in productivity.
The Scenarios
When discussing the differnt types of operator, I juxtaposed big and small companies as their differnce is obvious. But I also mentioned companies with an IT oriented business model, so other factors determine the operational requirements as well.
Instead of company size, I will thus divide the scenarios by complex and simple production environment.
On the application side, we saw how differently microservices deal with operational requirements. Therefore the distinction between operator types mainly applies to traditional applications, while microservices are altogether differnt anyway.
This results in the following scenarios:
- traditional applications in a complex production environment
- traditional applications in a simple production environment
- microservice environments
As anounced above I will discuss various aspects of operations along these scenarios. Solutions for scenario 2 are also relevant for running projects as a hobbyist.
We need the Wompom!
Many providers of IT products are trying to transfer legacy products to SaaS offerings. Managers avoid to develop brand new systems from the ground up, replacing the old ones in “big bang” fashion as this requires a duplication of the team while the old application is still maintained and carries the risk of failing to provide the hoped for equivalent of the original application. As a result, this transition is done evolutionary and developers face the challenge of adapting to all 3 of the scenarios at the same time. Our application has to be as versatile as the Wompom in the Flanders & Swan song.
While changing a monolithic legacy system to a modern microservice application is a topic of its own, I will delineate possibilitis to fulfill all three of the above scenarios. While modern architecture can bridge contradicting requirements, avoiding decissions is not good prodcut management. It is generally important to focus on the points that matter and say “no” to reuqirements that do not fit in.
A Caveat on Categories
The above scenarios are archetypes and reality is likely not to match them completely. Categories should always be taken with a grain of salt. They should help to understand reality, but not bend reality to fit.