DEVOPSdigest

In today's hyper-digital world, organizations and their developers are having to deliver faster go-to-market innovations than ever, which can mean siloed applications and rising integration challenges — otherwise known as spaghetti architecture — instead of stable and resilient ecosystems.

Spaghetti architecture is an information technology problem that hinders businesses’ ability to rapidly transform applications and data to meet ever-changing requirements. Therefore, organizations should consider incorporating DevOps and Site Reliability Engineering (SRE) best practices as architectural philosophy in their DNA — rather than checklist items — to create resilient and scalable architecture.

While it is extremely important to build each application with all the right security constructs, it is far easier to build a secure individual application than an entire ecosystem with multiple applications. Therefore, vulnerabilities invariably exist in between systems that must interoperate. Incorporating best practices is a mechanism to systemically increase the resilience of ecosystems that power businesses.

IT professionals must therefore recognize that best practices are not piecemeal; they reduce risk when applied appropriately together in an architectural paradigm with a holistic approach to drive security, reliability, scalability, and maintainability.

So, what are the three best practices, and how can companies implement these to streamline processes at the application and ecosystem level?

1. Distributed Applications and Data

Breaking large, monolithic systems into smaller elements or units — a design principle known as separation of concerns (SoC) — immediately reduces the blast radius and susceptibility to ransomware attacks.

A database broken into smaller units, like in healthcare, could involve separating protected health information (PHI) and personally identifiable information (PII) so that this sensitive data becomes anonymized. The anonymity ensures a higher level of security since the data cannot be compromised. Plus, the setup becomes far more reliable because only a portion of the system would be down at any one time, rather than the entire monolithic system.

Distributed systems also mean that smaller IT teams can build individual units using the technology of their choice, based on specific standards. The smaller units can be scaled individually by being deployed on commodity hardware to get the greatest amount of useful computation at a low cost.

The smaller units become highly maintainable since the distributed teams have their own independent development executives. Maintainability is an underappreciated item, especially in the developer community, because many are thinking about how to build a system in the first place instead of how it will perform over time.

When we talk about distributed systems today, you’ll see that microservices architecture and going serverless are the most popular implementations, with the serverless market set to grow to $21.9 billion by 2025.

2. Network Isolation Control and Principle of Least Privilege

Securing distributed systems involves segmenting functional servers or resources into separate virtual networks with distinct levels of trust and access controls. This is a mechanism to control potential damage in case of a security breach too. Most cloud providers offer native capabilities to create such network silos (or zones), including the two most deployed, Virtual Network (VNet) from Azure and Virtual Private Cloud (VPC) from AWS.

It is vital to ensure that the connection between your isolated networks is not persistent but transient — and based on the Principle of Least Privilege — with an appropriate type of authentication and authorization protocol (OAuth 2.0 based OpenID Connect or SAML) used at the application and infrastructure level.

Having data on separate virtual networks ensures reliability, scalability, and security due to their load balancers, auto-scale factors, and caching. This, in turn, helps with geographic redundancy and backups to guarantee that, even when disasters happen, critical applications remain available. Implementing automation and very strong DevSecOps would be essential to keep this a maintainable best practice.

3. Visibility, Observability and Traceability

How can you secure something unless it is visible? CIOs should constantly be on top of how many applications, servers, and databases they have running, and have an idea of the health metrics associated with each of these.

You may be wondering how you gain access to this overview. Instead of disrupting engineers’ and developers’ workflows, look to automation platforms and DevSecOps professionals to deliver tech-enabled business outcomes.

By having advanced observability across cloud-native environments, cross-functional teams have access to the right level of logging, alerting, and monitoring to better understand complex distributed systems. Every compliance authority requires access controls from logging but, more importantly, it helps companies have an overview of and updates about system health, incident response, and threat detection.

Furthermore, infrastructure monitoring tools detect and debug performance issues by analyzing application metrics, traces, logs, and user experience data.

Traceability ultimately means that the smaller distributed systems can be put back together accurately. If something fails, developers would be able to trace it back and determine what caused the outage, breach, or hardware failure. This allows businesses to scale freely, without the worry that they’ll be caught out in the future.

Final Takeaway

The challenge that companies face is that developers are not natively trained on these aspects of best practices. As much as organizations and technology leaders are aware of this responsibility, incorporating best practices still seems an afterthought (especially when you have multiple legacy systems).

Every application in the ecosystem has to be built in a sustainable, secure, scalable, and reliable way — a holistic architecture — which can only be achieved if best practices are seen as a cohesive whole rather than checklist items. You cannot retrofit a tool into a systemic gap to bring about security and integration — that would leave you with spaghetti applications.