This allows developers to” race with the scissors ” to develop apps quickly – and still safely
Developers are in a bind: they must quickly create new code, otherwise the company will lose market share. However, errors can lead to application failures, damage to reputation or even data loss. The combination of DevOps, orchestration, container and cloud offers a way out.
Companies on the topic
Just as scissors can make code dangerous, developers should work accordingly as carefully as quickly.
“Before COVID, it took us six months to a year to launch a new application, now it only takes six weeks.”This is reported by the person in charge of a company. Although it has long been known that you have to develop apps quickly, but now the time pressure is getting stronger and stronger.
Many companies simply tell their developers to hurry. And they plan, program and publish the code in a fraction of the time so far. But be careful: even in kindergarten you are warned to be calm and careful with the scissors in your hand – or even to run with them.
A developer’s new code – the scissors, so to speak-can do a lot of damage if it is used too quickly and carelessly. If the code is not sufficiently tested and errors creep in, business-critical applications may fail, the reputation of the company will suffer and customer data will be compromised. However, with more time and care, companies may lose market share to their faster competitors.
Everything you need already exists
To escape from this predicament, developers need to work quickly and safely with the scissors. The necessary tools and processes are already available. This allows DevOps teams to automate the release process. Tools for continuous integration and deployment (CI/CD) as well as orchestration are mature – as are technologies for containers and cloud-native architectures.
The trick now is to combine these different solutions in a suitable way. The focus is on the concept of microservices: a large application is divided into small, discrete functions. These are reusable and optimized for the respective teams, tools and technologies. If errors occur with microservices, they only affect this one function and not the entire application.
In a hybrid architecture, microservices environments can be used alongside legacy applications. By decoupling the functions from the overall architecture of an application, developers can test and deploy the necessary code themselves. This allows Canary tests, blue-green tests and A/B tests to be carried out without contacting the infrastructure teams or waiting for a maintenance window.
Transparency and orchestration needed
But this is only half the solution. The visibility and coordination of the workflows must also be ensured so that all participants are on the same level. The introduction of an abstract layer that sits above the application delivery infrastructure solves the problem of software network integration. But if these layers do not communicate with each other, another silo has been created. Then the problem was only shifted from hardware to software.
For many companies with complex workflows, it doesn’t matter how quickly the developers make a change, because the security managers still have to check the code or change a firewall rule. This often forms the new bottleneck. On the one hand, changes made by up to 50 different app teams-each working on their own microservice – have to be taken into account, as well as numerous internal and external guidelines. Given the necessary care, security teams are usually unable to handle this amount in a short period of time.
Ultimately, there needs to be a way to provide transparency, orchestration, and automation to eliminate transfer points and the resulting friction between different teams such as development, DevOps, Infrastructure & operations, and security. Until now, there was a solution option in a vertically integrated platform that does this. Providers of platform-as-a-Service (PaaS) and infrastructure-as-a-Service (IaaS), for example, pursue this approach.
The flip side of the coin: application services are then linked to the underlying infrastructure. Thanks to the simplicity of the all-in-one approach, companies can be faster at the beginning. But later you may find that your adaptability is impaired. If you obtain all tools and services such as database, firewall, WAF, DNS, Ingress Controller or API Gateway from a cloud provider, this leads to the so-called vendor lock-in.
Moving to another cloud to use more attractive services from other providers is almost impossible. With a major change like a takeover, you can’t quickly merge different systems, migrate to a new cloud, or bring an application back to your own data center.
Instead of this vertical integration, where app, app services and infrastructure are closely linked, the horizontal approach is to integrate across different cloud providers. In such a multi-cloud approach, applications can be operated independently of the infrastructure used. This can be realized relatively easily with the help of microservices, which have corresponding APIs.
An infrastructure-independent application delivery offers a user interface across all larger hyperscalers and your own data center. This enables infrastructure-relevant services such as Ingress Controlling, WAF or authentication to be implemented in the same way with any cloud provider. A change to another provider or a mixed operation is possible at any time.
Current technologies offer transparency, workflows and APIs at all stages of the application lifecycle. A new abstraction layer automates and ensures both the deployment and the security of the applications in all processes of the company. The developers are also allowed to run fast with the scissors in their hands, as safety is guaranteed at every stage.
* Roman Borovits is Senior Systems Engineer at F5.