Modern application development: From Legacy, through DevOps, to ZeroOps

Modern application development: From Legacy, through DevOps, to ZeroOps

I think we can all agree that modern application development can be a challenge. From application architecture decisions, to sourcing and selecting frameworks, to dependency management,...:  Developers have a lot to think about.

In many cases building the application is only one component. Security, reliability, and maintenance of the application are all considerations of modern application developers.In addition to all these things that take up developer headspace and capacity, in many cases, spurred on by the DevOps movement, we have also come to expect that developers should act as or be system administrators, IT architects, and infrastructure operators. 

So how did we get here? And is there a better way?

I believe there are three distinct eras that will help us understand how we got here, and what we can do about it. Let’s look at:

  • The Legacy era
  • The DevOps era
  • The Platform era


The Legacy era

In the Legacy era there are two independent teams, the Development Team, and the Operations Team. There is no overlap between these teams, and often interaction between these teams have to go through formal processes (such as support requests from the developer to the operations team to get a new production or development environment created.)

In the Legacy era, the developers build applications, test them on development and staging environments, and then when ready “throw a request over the fence” to get the applications deployed to production.

In the Legacy era we find a lot of unhappy developers, and a lot of unhappy operations people.

No alt text provided for this image

In the fast-news-cycle and social-media world of today, development teams often need to move quickly. They need new production environments quickly, and they need development and testing spaces quickly. But everything needs to go to the Operations team who have different goals and different priorities. 

The operations team is also unhappy. Their performance is measured by service uptime, reliability, performance, and security. In order to meet these goals, things should change infrequently, and when changes are needed, they need to be planned out and signed off. 

On top of this, the bias to operational performance and KPIs means that development or non-production environments are often an afterthought, and are seen as an overhead instead of a core requirement, creating more developer unhappiness.

There must be a better way right?

The DevOps era

People from the Legacy era got together to tackle the question. They realised that a significant source of the problems in the Legacy era are due to the silos between developers and operations. They came up with and embraced a new philosophy, and the DevOps era was born.

DevOps was conceived as a mix of principles, practices, and tools which when coordinated can increase a teams application delivery and service reliability. Ultimately this leads to an ability to evolve and improve products much more quickly than competitors operating in the Legacy era, and this speed and efficiency leads to increased customer satisfaction and ultimately a more competitive market positioning.

No alt text provided for this image

In the DevOps era, developers and operations teams are merged into one team, measured by the same success factors, with common goals and incentives.

Things are definitely better in the DevOps era. The most effective teams are organising cross-functional collection of generalists and specialists from the different parts of (often previously siloed) development, operations, engineering, security, and QC teams who are empowered to continually self-organise as their work evolves, and are encouraged to embrace automation through the implementation of existing tools, and the development of bespoke tools in order to remove the barriers inherent in manual processes, especially as these relate to the teams deployment frequency and deployment velocity.

However, as time goes by, both developers and operations people are becoming less happy under the DevOps era as well. The primary reason is that developers are increasingly expected to know about the infrastructure and its operations in order to be part of the team, and visa-versa, operations people are expected to know more and more about the application development workflow and application architecture. 

Things are still much better than they were in the Legacy era, but while the DevOps era broke down the silos, it inadvertently increased the number of things both developers and operations team members need to know and care about.

There must be a better way right?

The Platform era

While the developers and operations people were busy figuring out the principles for effective collaboration in the DevOps era, technology was steadily moving forward. One of the most important things to happen was the development, stability, and maturity of application containerisation.

Containerisation is the process of packaging software code into a single lightweight executable, or container. This single piece of software, or "container," is separated from the host operating system. Most importantly, applications can be "written once and run anywhere" with containerisation. This portability accelerates development, prevents cloud vendor lock-in, and provides additional notable advantages like fault isolation, ease of management, and simplified security. 

The open source Docker Engine, an industry standard for containers with simple developer tools and a universal packaging approach, rose to prominence in 2013 and accelerated the adoption of this technology. Containers are more portable and resource-efficient than virtual machines, and have become the standard computing platform for contemporary cloud-native applications.

The emergence of containerised applications allows for a clear separation of responsibilities in the the Platform era. Increasingly the DevOps teams realised that as long as application developers could containerise their applications, the operations teams could focus on delivering a platform that is capable of running these applications in a reliable, secure, and scalable way. 

So in the era of the Platform, the operations team morphed into a platform team, and operations in the traditional sense faded away. Without Operations, the term “DevOps” makes no sense, and so the philosophy underlying the day-to-day life in the Platform era came to be called “ZeroOps” or NoOps.

No alt text provided for this image

Exploring the ZeroOps Platform from amazee.io & Mirantis

With a Platform and Platform Team in place, Developers can consume services provided & managed by the Platform team. 

Running containers

One of the primary services of the Platform is the ability to deploy application containers into the Platform in a consistent way, multiple times as they need. Deployments to production and non-production environments should work in the same way so that developers can write code and have it integrated, tested, and deployed in a low-friction-high-velocity way.

amazee.io leverages Kubernetes, also known as K8s, an open-source platform for managing, scaling, and automating containerised application deployment and management. Kubernetes expands upon 15 years of battle tested containerised application responsibilities at Google.

Deploying applications

Lagoon (www.lagoon.sh) is the open source application delivery platform for Kubernetes. Its primary focus is as a cloud-native tool for the deployment, management, security and operation of containerised applications. Kubernetes manages, runs, scales, schedules containers in Kubernetes Clusters, in order to allow developers to consume an application delivery service, a consistent approach to application delivery is needed.

Lagoon makes the deployment process of any application into a Kubernetes cluster very simple:

No alt text provided for this image

  1. Developers push code into any Git Repository
  2. Lagoon Core gets informed from Git Server about new code via a Webhook call
  3. Lagoon Core tells respective Lagoon Remote to start deployment
  4. Lagoon Remote starts the deployment
  5. Lagoon Remote tells Lagoon Core about deployment Status
  6. Lagoon Core informs Developer about Status (UI, API, Chat, Webhooks, etc)

As part of the responsibility of the Platform team, Lagoon greatly reduces the requirement on developers to have any cloud-native experience or knowledge.

Cloud-congruent local development experience

One of the identified problems from both the Legacy era and the DevOps era was that operations teams are primarily focused on the production environment, and non-production environments are at best and afterthought. 

Local development is even less of a consideration for legacy and DevOps operations teams. However, generally speaking, developers spend the majority of their time working on their applications locally. So one of the biggest efficiency hacks available to make more productive developers is to increase their ability to run the same software locally, in the same way, as it runs in the cloud.

amazee.io and Lagoon provide a local development approach which allows developers to quickly and effectively run their applications locally on their computers, along with copies of the cloud environment files and data. Access to the ability to replicate the cloud environments is controlled by the Lagoon role-based-access-control.

True Platform as a Service

Leading organisations are establishing Platform teams to ensure the most friction-free end-to-end developer experience. Platform teams own internal workflows, tools, and platforms to ensure developers are shielded from the emerging complexities of the underlying infrastructure. 

Platform teams require specialised experience, 24/7 operations, and ongoing maintenance and security. World-class Platform teams create a smooth development and deployment experience for everyone involved. 

Instead of building your own platform, the amazee.io Platform Team can slot in seamlessly with your organisation, delivering the Platform experience discussed here to your organisation on your preferred infrastructure provider.

ZeroOps - The future is now

As we’ve said before, ZeroOps is a set of practices that result in developers focusing solely on coding and creating, with 0% of their time spent on operations or infrastructure. The bottom line is, much less ops. Much more time for coffee. 

We believe that ZeroOps is the key to sustainable and productive teams. Without worrying about infrastructure and operations layers, your team can focus on executing new ideas and completing the projects that bring real business value. 

And lets not forget, the benefit of a world class ZeroOps application delivery platform is that it offers support for all major web technologies and frameworks, giving your team and your business the freedom to choose what’s best for your business context, your processes, and your organisation. 

While DevOps went some way to solving the problems we found in the Legacy era, and the same people are still technically a part of a Platform solution approach, I firmly believe that ZeroOps is the future.

#lagoon #applicationdelivery #platform #kubernetes #k8s #devops #zeroops #noops #opensource #paas #platformengineering #webops #cloudnative

To view or add a comment, sign in

More articles by Martin Schlögl

Others also viewed

Explore content categories