Continuous Application Development - Integrating Platform Engineering for Enhanced Deployment

In recent years, teams have discovered that the way they approach software development can wield a profound influence on their business outcomes. Organizations that possess the capability to not only integrate their ideas into their codebase but also expedite their journey to production gain a distinct competitive edge.  By developing better continuous application development processes, teams can assure themselves that they’re shipping code faster, with fewer bugs, with less effort, and at less cost compared to a more manual or traditional software deployment process. As companies found increasing value in continuous application development processes, a new practice has emerged called “Platform Engineering.” Throughout this post, we’ll explore how continuous application development relates to Platform Engineering and explain how Portworx fits into this new approach to getting software into production.

Continuous Application Development

For those with experience in the information technology field, the traditional path from coding to production deployment is a familiar one, typically divided into two distinct phases: Coding the application and deploying it.

Historically, application developers took a business idea and transformed it into code. When they had finished writing their code, they needed to engage with a separate team to transfer that code onto servers and into an environment for testing and eventual production deployment. While this process worked, it was often cumbersome and time-consuming for both teams, even when good communication was in place. Applications frequently encountered issues after deployment, necessitating more coding and re-deployment efforts. This not only consumed developers’s time, but also added considerable work placed on System Administrators tasked with software deployment activities.

This archaic process of requiring people to push code into production got a significant boost when infrastructure components were placed behind an application programming interface (API). The advent of cloud computing made the manual deployment process more easily automated through Infrastructure as Code (IaC). With teams now equipped with their own APIs for the infrastructure, application deployments could automate the code deployment process without as much human interaction. This automation not only reduced deployment times but also eliminated human error for repeat deployments. As these automated routines evolved, some were given directly to development teams, giving them the autonomy to deploy their own software without relying on the System Administrators. By giving the ability to deploy their own code to a testing or production environment, development teams gained increased deployment velocities because they removed the time waiting for another human on a different team to deploy their software for them. This seemingly simple process change introduced the ability to update applications very quickly, compared to the old method, and having quick deployment routines gave developers a wealth of capabilities including:

Smaller Code Changes – Developers didn’t need to package large numbers of updates together before requesting it to be deployed to a server. Since code can be deployed quickly, smaller updates can be coded, tested, and pushed to the application’s main branch. These smaller code changes reduced merge conflicts between development teams and helped to improve deployment frequency.

Fast Feedback – Application teams could introduce functional testing into their application development routines by automating any integration tests needed to be run against deployed code. Instead of integration testing happening manually after another team deployed their app, this testing could happen immediately after an application is deployed, giving the developers faster feedback.

Fewer Bugs – Integration tests and smaller code changes compounded themselves, and the result was fewer bugs being pushed to production.

Less Wasted Time – Developers no longer needed to spend so much time being idle while they waited for code to get deployed to servers. Now they could perform these activities themselves, and on their own schedules.

With developers now capable of deploying their own code to production, the old two phase process of “coding the app” and “deploying the app” became known as the inner loop and outer loop of the software development cycle. The inner loop focuses on coding, unit testing and application code-centric activities in a local development environment like a developer’s laptop. The outer loop concentrates on deploying code to testing environments, staging, and eventually production, with the required integration testing taking place post-deployment.

Today, when we put these two phases together, we typically refer to them as Continuous Delivery or Continuous Deployment routines that encompass the entire process of coding an app, performing unit tests, integration tests, acceptance tests, and finally deploying the app to a production environment.

Introducing Platform Engineering

Having infrastructure as code altered the way we perceive the software development lifecycle (SDLC). Developers had more power and control over their workday like never before. These new capabilities provided a new way of operating business applications, sparking the backdrop for Werner Vogels to state the principle of “you build it, you run it” in an interview in 2016. Having infrastructure APIs to code against certainly gave them more flexibility, but also increased their cognitive load.

Developers who were accustomed to implementing application code suddenly found themselves grappling with operational topics, increasing their cognitive load and actually hindering productivity. The industry witnessed the rise of discussions around “10x Engineers” or “Full Stack developers” as companies sought unicorns capable of handling all of these activities related to their application stacks.

The rising cognitive demands placed on developers were a catalyst for Platform Engineering. Platform Engineering centers on providing a streamlined process for deploying development code into a deployment environment, sparing development teams the need for deep expertise in system operations and system management, and eliminating the need for expensive “Full Stack” engineers. This task of helping developers achieve a smoother transition from “code built” to “code deployed,” isn’t a new concept. Many companies have made concerted efforts to foster communication between operations and development teams, aiming to optimize the entire process, not just for code deployment but also for smoother operations once that code goes into production. However, what we’ve come to realize is that simply encouraging System Administrators and Developers to work more collaboratively is insufficient. Instead, there is growing recognition that a dedicated team of people is required. A team who are solely focused on getting developers’ code into production in a manner where an operations team can manage it effectively while minimizing cognitive load on all parties involved.

Platform Engineering teams are becoming the lynchpin to the continuous application development process. They sit in the middle of this DevOps Venn diagram and need to enhance the capabilities of both developers and operations team’s so that they can get deployment velocity developers are seeking with the reliability that operations teams require. Here are some key concerns that Platform Engineers need to address:

Streamlined Development Process – Provide that Infrastructure as Code and self-service capabilities that developers have gotten accustomed to, so that we can get fast feedback, fewer bugs, and less wasted idle time. This often means integrating with development teams CI/CD process to perform automated functional testing after the apps are deployed.

Standardization – Reduce the complexity of deployment environments by standardizing the deployment method used by developers. As an example, the same deployment method provided by an internal developer platform (IDP) might be used regardless of whether that application is deployed on a public cloud or on-premises.

Reliability – Ensure that code deployed through the IDP is deployed with high availability, disaster recovery, security, fault-tolerance, and performance needed for any production enterprise application.

Compliance – The IDP can make sure that developers are deploying applications that meet corporate standards for compliance through codified routines.

Platform Engineering must design systems that take into account requirements and constraints of both the development teams, and operations teams so that they can facilitate high-velocity application deployments, within corporate standards all while reducing the cognitive load on the humans using them every day.

The Role of Portworx

Platform Engineers have taken on the burden of this cognitive load of knowing how applications should be run in production. They have an enormous responsibility to make sure that code is deployed quickly, but reliably and securely in many target environments. It’s not uncommon to find Platform teams needing to deploy code on-premises and across one or more cloud environments, and each of those environments have vastly different solutions to do this. While Kubernetes is not a prerequisite for an internal developer platform, it provides a standardized solution that operates consistently across environments.

Kubernetes equips Platform Engineers with fundamental capabilities that can be rapidly implemented regardless of the environment. Instead of writing three deployment routines for three different cloud providers, the platform teams can leverage Kubernetes capabilities that are uniform everywhere. Kubernetes offers service discovery and load balancing, scaling, rolling updates, secrets management, quotas, networking and self-healing for containers. This makes Kubernetes a really valuable tool for Platform Engineers because every one of these capabilities is provided by default regardless of the environment you’re running the cluster on, and is one reason Platform Engineers choose Kubernetes.

Portworx has a similar value proposition for Platform Engineers who need to ensure their apps work the same way across environments. Like Kubernetes, Portworx provides a basic set of capabilities, but these focus on storage primitives. We know that before you can deploy applications to production, things like backups and disaster recovery routines need to be in place. We know that the security teams are going to require that we have encrypted our sensitive data. We know that our data needs to be highly available to prevent issues with zone or node outages. We know that our application data will grow, and we need auto-scaling features to manage that data when it does grow. Portworx is providing these multi/hybrid cloud capabilities out of the box for Platform Engineers to utilize instead of building bespoke solutions for every environment.

Summary

We’ve vastly improved our capabilities to deploy workloads quickly by leveraging APIs and Infrastructure as Code, but this lays a heavy cognitive burden on the developers who might want to use it to deploy their code. Platform Engineering was built to streamline the process to continue to allow development teams to deploy their software quickly, but with the appropriate operational guardrails the business needs, all while limiting the amount of information people need to properly deploy their applications. Kubernetes has become a common container platform across clouds that provides internal developer platforms with quick capabilities that run across multiple clouds, and Portworx provides those common storage attributes that can be quickly leveraged by Platform Engineering teams.

To learn more, check out the second blog in our Platform Engineering series, where we discuss how applications can be built once, ported anywhere, and run everywhere. Portworx recently also hosted a webinar focusing on Continuous App Development which you can find here.