A developer that deals with the following list of pain points.
1. Disaster Recovery Strategy
2. Environment Configuration
3. Security Posture
4. Vendor Opt-In / Opt-Out Strategy
5. Dependency Management
There are multiple control planes for applications that affect how these pain points can be addressed and resolved.
This article takes the perspective of a pure application developer working on enterprise issues, looking through each control plane, and attempting to leverage standard practices across industries , backed by successful outcomes.
One of these successful models from a specific industry we are most familiar with is , Kaizen. Continuous improvement started in the automotive sector then used by agile software teams at Microsoft, Netflix, Google, Amazon, and countless others.
The value is easy to spot. These companies provide seamless customer experiences, and the complexity of what they are doing is hidden.
Netflix pioneered streaming architecture.
Amazon pioneered virtual private computers.
Google gave us MapReduce and Kubernetes.
Microsoft has dominated the Fortune 500 enterprise space with products like Office 365.
Companies are no longer doing everything, and they trust experts in the space to formalize concepts and provide a façade to downstream collaborative consumers. Much like, the peloton formation bikers and marathoners use to support the fastest individual. A group of individuals subdivides on coming friction from the wind to the point where one individual in the group feels little to no resistance.
How much do the systems you use today cause friction in your workflow when developing durable applications?
This article is a summation of the knowledge gained and an analysis of how this process occurs today. By no means is this a recommendation for how to do things, and I hope the reader will take away the cases and models used as another tool in their toolkit to provide exceptional user experiences.
What is a durable application?
A durable application is something that stands up against repeated failures. While that may be simple at face value, it can get tedious when dealing with low-level systems. Working with failures has become routine. As a pragmatic developer, it is essential to leverage time and proven mechanisms. The less time spent on regular maintenance means more time spent providing direct value to customers.
Developers worldwide are starting to receive specs that ask for basic features.
Serializable
Portable
Monitoring Capabilities
Logging
Resilient
Smooth UX
Intuitive UI
Most of these areas have experts who have identified the problems in each space and solutions, along with tradeoffs.
Most commonly, these experts have open-sourced their solutions and have begun consolidating around an Open Application Model, which is what I'm going to refer to in this article as a durable application.
The open application model enables developers to benefit from complex tooling without knowing the internals of the tooling.
Developers are often able to learn new tools quickly because of the nature of the work. When a developer gets a specification, the next step is to compile complex requirements.
Today that might look like React or Vue on the frontend. Python on the backend. Kafka for publish subscribe messaging. REST for service communication. Data Orchestration tools for distributed data processing. Kubernetes for cluster management.
We have to some extent, 90% consensus on how to build. There are clear winners in enough tooling space where novice developers can be highly productive without understanding how Kafka, Kubernetes, React, Vue, and Python internals work.
Knowing how the internals work is highly beneficial and helps with modeling solutions, but it is no longer critical because of the software solutions' communities. The Open Source Initiative is the common thread to all these solutions that have dominated the application developer space.
Open Source projects promote a healthy bit of collaboration. The communities handle, to some degree, bugs, updates, and innovation. On top of that, some open source projects often have an Enterprise Tier/Version of support that is a 24/7 priority, provides SLA agreements, and compliance with GDPR, HIPAA, SOC I & II.
As an application developer, I get a secure and stable tool that follows common practice and support through a community if I encounter issues. If the community does not solve the problems, I can tackle them myself, including learning the tool's complexities or looking for Enterprise Support to expedite that process.
Open source tooling that caters to application developers at the command line is table stakes.
The most successful tool that follows this pattern is Kubernetes, and it dominates cloud infrastructure today.
It has become the agreed way for application developers to migrate into cloud environments.
The problem
Kubernetes is complicated. It takes a long time to learn, requiring a very different skill set and mental model than most application developers have built up over the past decade. Application developers have usually dealt with the following concepts
Document Application Model (DOM) on the frontend.
Representational State Transfer (REST) or Remote Procedure Calls (RPC) on the backend
Monolithic Architectures
Moving to the cloud requires learning a few new models related to
Microservice Architecture
Distributed Systems Secure Networking
Distributed Systems State Management
Authorization and Authentication with Cloud Providers
Canary/Blue/Green Deployment Strategies
The solution
Use tooling that supports the following capabilities
Cross-Platform Development
Logical Splitting of Monoliths
Abstraction over distributed systems
Multi-Target Deployment Strategy
Specific methodologies or libraries are replaceable, using plug and play.
How to use durable applications in the real world?
Empower people at various technical levels to leverage modern cloud-native technology to develop their solutions and opt-in to managed solutions without slowing down the iterative problem-solving. More importantly templates are generated in json, yaml, arm, bicep for other teams to make the appropriate edits.
Develop an Infrastructure-As-A-Service platform that allows for rapid provisioning of services that are specific to policies for organization and tailored towards specific use cases.
Enable Developers to contribute to the Infrastructure-As-A-Service platform.
Develop a Software Catalog of services for development teams, business users, and executives to support improving the customer experience.
Was this page helpful ?
Want to contribute or give feedback ? Send me a tweet or DM me on twitter 👇🏿
Loading…
Want to print your doc? This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (