In our previous post, we explored the challenges of monolithic architectures and the potential pitfalls of mono repos. We saw how engineers often find themselves trapped in a cycle of adding to existing monoliths, despite the long-term drawbacks. Today, we’re excited to introduce a concept that offers a way out of this dilemma: Paved Paths.

What is a Paved Path?

A paved path is a supported technology stack within an organisation that provides a clear, well-maintained route for developing new features or systems. It’s not about dictating a single way of doing things, but rather about offering a smooth, well-supported path that makes it easier to create new services or applications without sacrificing speed or quality.

Think of it like this: when you’re walking through a park, you’ll often see paved paths alongside open grassy areas. While you’re free to walk anywhere, the paved paths offer a clear, easy-to-follow route that most people naturally gravitate towards. In software development, a paved path serves a similar purpose.

Components of a Paved Path

A well-implemented paved path typically includes:

1. Shared Libraries: Reusable code components that handle common functionalities like authentication, logging, or database access.
2. New Project Templates: Pre-configured project structures that set up the basics of a new application or service, complete with best practices baked in.
3. Infrastructure as Code: Templates for setting up the necessary infrastructure, ensuring consistency across different projects.
4. CI/CD Pipelines: Pre-configured continuous integration and deployment pipelines that work out of the box with the new project templates.
5. Monitoring and Observability: Built-in solutions for logging, metrics, and tracing that integrate seamlessly with the organization’s existing tools.
6. Documentation and Guides: Comprehensive resources that explain how to use the paved path effectively and when it might be appropriate to deviate from it.

Benefits of Paved Paths

Paved paths offer numerous advantages that address the issues we’ve discussed with monoliths and mono repos:

1. Faster Start-up: Engineers can quickly spin up new services or applications without spending weeks on boilerplate setup.
2. Consistency: All new projects start with a consistent structure, making it easier for engineers to switch between different services.
3. Best Practices Built-in: Security, performance, and scalability best practices are incorporated from the start.
4. Easier Maintenance: With a consistent structure across services, maintenance becomes more straightforward.
5. Flexibility: While providing a clear default path, paved paths still allow for deviation when necessary, offering the best of both worlds.
6. Improved Onboarding: New team members can get up to speed quickly by following the paved path.

Striking the Right Balance

It’s important to note that paved paths are not about enforcing a rigid, one-size-fits-all approach. They’re about providing a well-supported default that makes it easy to do the right thing, while still allowing for flexibility when needed.

Paved paths coexist with what we might call “rough paths” – less travelled routes that engineers might choose to explore for various reasons. These rough paths could be new technologies, experimental approaches, or simply different ways of solving problems that don’t quite fit the paved path model.

The beauty of this approach is that it encourages a balance between standardization and innovation:

Engineers are free to venture off the paved path when they believe it’s necessary or beneficial. This openness to exploration prevents the stagnation that can come from overly strict standardization. As engineers explore these rough paths, they gather valuable insights and experiences. Some of these explorations might reveal better ways of doing things or address use cases that the current paved path doesn’t handle well.

The most successful “rough path” explorations often lead to the creation of new paved paths. This evolution ensures that the organization’s supported technology stack remains current and effective.

By allowing and encouraging these explorations, organizations tap into the collective wisdom and creativity of their engineering teams. This bottom-up approach to defining best practices often results in more robust and widely-accepted standards.

As the LinkedIn engineering team learned when they tried to standardize on a single tech stack, too much restriction can stifle innovation and lead to suboptimal solutions. Paved paths strike a balance by offering a smooth road forward without blocking other routes entirely.

This balanced approach creates a dynamic ecosystem where paved paths provide stability and efficiency, while the ability to explore rough paths ensures adaptability and innovation. It’s not about dictating a single way of doing things, but about fostering an environment where best practices can emerge organically and evolve over time.

Conclusion

Paved paths offer a promising solution to the challenges posed by both monolithic architectures and the complexity of mono repos. They provide the speed and ease of development that often draws us to monoliths, while enabling the modularity and scalability that we seek from microservices.

In our next post, we’ll dive deeper into how you can implement paved paths in your organisation, with a special focus on using .NET templates to create a smooth path for your development teams. Stay tuned!